webpack 开始提示包太大以后，很多人的第一反应是“那我多写几个 import() 吧”。动态导入当然是重要工具，但如果拆分点没有顺着页面路由和功能边界走，只会把一个大包拆成很多难管理的小包，首屏和切页体验未必真的更好。

webpack 的性能优化很容易让人一上来就陷入“经验动作”：先怀疑 UI 组件库，再怀疑图片，再想办法加几个拆包配置。可如果还没看清产物里到底是什么占了体积，这些动作大多只是碰运气。真正有效的优化，通常都从一份可读的打包分析开始。

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

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 先分好，觉得以后扩展会方便。可项目在功能还不稳定的时候，包分得太细，往往比全写在一个地方更容易把自己绕进去。