一介布衣

写前端小插件最容易带来的错觉，就是“东西很小，怎么写都行”。尤其做分享按钮、浮层、复制链接这类轻量功能时，很多实现一开始都很快：挂几个全局变量、塞一段样式、暴露一个初始化函数，页面立刻就能用。

VSCode 真正用顺以后，很多人都会开始调设置。问题也从这里开始：个人用户设置越积越多，项目工作区设置也越来越重，到了某个节点，大家会发现格式化、补全、保存动作、插件行为全在互相覆盖，谁说了算都不清楚。

表面上看，CommonJS 迁移到 ES Module 很像一次语法替换：require 换成 import，module.exports 换成 export。可 2019 年前后我自己在项目里碰这件事时，真正拖慢进度的从来不是语法本身，而是模块边界和运行上下文没先想明白。

刚从 GOPATH 思维切到 Go Modules 时，很多人最直观的感受是目录终于自由了，不一定要把项目放在固定路径下。可真正让我觉得它实用的，是本地联调依赖仓库时，不用再靠复制粘贴代码或者临时改 import 路径硬顶过去。

Go 初学阶段很容易把 slice 和 map 当成“比数组和字典好用一点的容器”。真正开始写业务后，很多让人困惑的 bug 其实都和这两个基础类型有关：为什么函数里改了 slice，外面数据也变了；为什么 map 还没赋值就 panic；为什么看起来只是截了个子切片，内存却迟迟下不来。

Go 学久一点以后，很多人都会记住一句话：interface 要小。但真到项目里，接口问题往往不是“大或小”这么简单，而是抽象出现得太早。实现只有一种、调用方式还没定稳，就先定义一堆 UserService、OrderRepository 接口，最后只会让代码多一层跳转。

刚开始写 Go 的时候，很多人会觉得错误处理很重复：每层都要判断 err != nil，看起来很机械。可真到了线上排查问题时，最怕的不是判断多，而是最后拿到的错误只有一句 “open failed” 或 “query error”，根本不知道是哪一步出的事。

很多人刚写 Go 项目时，最有安全感的动作就是先把目录搭完整：controller、service、dao、model、utils 先分好，觉得以后扩展会方便。可项目在功能还不稳定的时候，包分得太细，往往比全写在一个地方更容易把自己绕进去。

第一次把 LevelDB 用进项目时，很容易被它的简单和直接打动：本地 KV、读写快、嵌入式、不用额外起服务。可也正因为它太像一个“很方便的本地抽屉”，很多人会自然把它当缓存来用，然后默认它应该顺便帮你解决缓存该有的那套问题。

Electron 最开始让人兴奋的地方，是你能用前端技术写桌面应用。可一旦真正接入 TCP 套接字、文件系统或者系统级能力，就会很快遇到另一个问题：主进程和渲染进程到底怎么分工？