网站本地测试

本地测试最烦人的网站不是代码报错，而是本地浏览器缓存。你改了CSS，测试刷新页面，网站样式纹丝不动。本地按Ctrl+F5强制刷新，测试还是网站老样子。最后发现是本地Service Worker在作祟，它在后台默默缓存了所有静态资源。测试清掉它，网站一切正常。本地这种问题浪费的测试时间，比写功能本身还多。网站

我习惯用Docker跑一套完整的本地本地环境。数据库、测试Redis、Nginx全塞进容器里，一条命令启动，一条命令销毁。这么做的好处是，测试环境跟生产环境高度一致，不会出现“本地好好的，上线就炸”的尴尬。但代价是内存占用高，笔记本风扇转得跟直升机似的。后来我学乖了，只把MySQL和Redis放容器里，Nginx直接用系统自带的，省一半内存。

本地测试有个隐蔽的坑——域名。直接访问localhost:8080，跟访问dev.example.com完全是两码事。Cookie作用域、CORS策略、HTTPS证书，全都不一样。我吃过一次亏：在localhost上登录没问题，部署到测试服务器后，登录接口一直报跨域错误。查了半天，发现是本地没走HTTPS，而生产环境强制HTTPS，导致Secure标记的Cookie发不出去。从那以后，我本地必配HTTPS证书，用mkcert生成一个，一分钟搞定。

接口mock也是个讲究活。前端依赖后端接口，但后端还没写好，怎么办？有人用Mock.js，有人用json-server，我倾向直接在Nginx里配一个反向代理，把/api开头的请求指向一个本地JSON文件。这样前端代码不用改一行，就能模拟各种返回数据。缺点是数据类型校验全靠自觉，后端真接口返回的数据结构跟mock不一致，又是一顿排查。

最后说数据库。本地测试最怕的是把生产数据搞乱，所以我会定期从生产库导一份脱敏数据到本地。但脱敏脚本得自己写，字段多了容易漏。更稳妥的办法是，用Docker跑一个独立的MySQL实例，每次测试完直接删掉容器，重新启动一个全新的。这样数据永远是干净的，测试结果也更有说服力。唯一的麻烦是，每次启动要等十几秒，但这点等待换来的是安心，值。

本地测试不是万能的。有些Bug只在特定网络环境或特定设备上出现，本地模拟不出来。但大部分问题，尤其是逻辑错误和样式问题，本地都能提前暴露。关键是别偷懒，环境越接近生产，踩坑越少。我见过太多人图省事，直接在本地跑个简单的静态服务器，结果上线后各种环境差异导致的Bug，修起来比写代码还痛苦。