把想法快速变成原型的三条笨办法
想法最怕停在纸上。我的做法是先把它压到最小可验证的一步：不求完整，只求能跑起来看一眼。于是多数时候不写界面，先用一段脚本把数据跑通，看到输出形态，再决定值不值得做下去。
第二条是尽量复用已有工具，而不是自己造。能在半小时内用现成组件拼出来的东西，就不花两天写一套新框架。第三条是留一份记录：当时为什么这么选、卡在哪一步，过几周回看往往比代码本身更有用。
助力创想空间，创新创意汇集
想法最怕停在纸上。我的做法是先把它压到最小可验证的一步：不求完整，只求能跑起来看一眼。于是多数时候不写界面，先用一段脚本把数据跑通，看到输出形态，再决定值不值得做下去。
第二条是尽量复用已有工具，而不是自己造。能在半小时内用现成组件拼出来的东西，就不花两天写一套新框架。第三条是留一份记录：当时为什么这么选、卡在哪一步，过几周回看往往比代码本身更有用。
小规模服务不一定需要框架。Node 自带的 http、worker_threads 和 node:sqlite 组合起来，已能覆盖路由、并发与持久化，部署时只要一个运行时，没有依赖树也就没有依赖冲突。
值得记的一点是读写分离：把数据库读写收进一个 worker 线程，主线程只负责收发请求与鉴权，通过消息传递交换数据。这样避免了多线程争抢同一连接，慢查询也不会直接卡住事件循环。代价是读取要序列化，所以传参时只带 key，不带整份状态。
另一个坑是语句对象的调用方式。把 stmt.all.apply(null,args) 这种写法搬过来会抛 Illegal invocation，必须先 prepare 再展开参数。
第一是尺寸的“所有权”。如果窗口高度由内容测量后上报，主进程就必须把这个值持久化，重建、切换形态、重启都沿用它；只要有一处回落到初始值，界面就会因为“高度没变”而不再上报，底部被永久截掉。
第二是事件监听的注册位置。写在创建界面的函数里，每次重建都会叠加一份，点一次按钮等于触发多次。第三是网络异常的兜底：断网时不要同步加载本地页，先延迟几十毫秒再切，否则容易在启动瞬间闪退。