很多人第一次排查 Docker 容器问题，都会先看日志。这一步当然没错，但如果只停在日志层，很容易卡住。因为容器问题经常不是单点故障，它可能同时涉及启动参数、挂载路径、网络配置、环境变量以及容器内部运行状态。

很多项目第一次做 webpack 缓存优化，都会先把文件名改成带 hash，觉得这样浏览器就能长期缓存了。这个方向没错，但如果 chunk 划分本身不稳定、运行时代码老是跟着变化、公共依赖和业务代码混在一起，最后会发现缓存命中率并没有想象中高。

webpack 配 source map 时，很多人最开始只有一个判断标准：能不能在浏览器里看到原始源码。可项目一大以后，你会发现 source map 其实牵连了很多事，构建速度、调试精度、错误定位、产物暴露范围，全都和它有关。选型如果只看“调试爽不爽”，很容易在发布阶段踩坑。

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；为什么看起来只是截了个子切片，内存却迟迟下不来。