我为什么建立这个博客：不想再把同一个坑踩两遍
发布于： 时间
有一次，我又遇到了一个明明解决过的 Nginx 问题。浏览器打开不同域名，却总被带到同一个页面。
我记得自己曾经处理成功，也隐约记得与配置有关，却想不起当时改了哪一段、为什么有效。于是我重新搜索、重新排查，又花了半个多小时回到原来的结论。
那一刻我意识到，解决过并不等于留下了经验。没有记录的答案，很容易在下一次报错时重新变成问题。
我想保留的不是一张成功截图
项目展示常常很整齐：功能列表、技术栈、最终界面。但实际开发的过程通常没有这么顺滑。
依赖装不上，CUDA 版本对不上，数据库连不上，Tomcat 不兼容，文件路径在另一台机器上失效，网页接口没有任何反应。这些过程不够漂亮，却最接近真实工作，也最值得以后回来查阅。
所以我希望文章不仅回答“最后怎么做”，还尽量保存这些信息：
- 问题出现时的环境与现象
- 我最初的错误判断
- 哪些尝试没有作用
- 日志或结果如何缩小了范围
- 最终方案为什么有效
- 方案还有什么限制
这比只贴一段最终代码麻烦得多，但也更可能帮助未来的我，或者碰到同类问题的人。
写不清楚，往往意味着还没真正理解
有些知识在脑中感觉很熟，一旦试着写成文章，逻辑就开始断裂。某一步为什么必要，某个参数改变了什么，我可能只能说“教程里就是这样写的”。
写作会逼我重新检查前提、过程和结论。它像一次没有提示的复盘，把那些只停留在模仿层面的理解暴露出来。
因此，这个博客也是我的第二个调试窗口。代码在终端里暴露错误，文字则暴露思路里的空白。
这里不会只有标准答案
我会记录编程、数据处理、计算机视觉、人工智能应用、服务器部署和项目复盘，也会保留一些没有达到预期的尝试。
文章会随着新的理解继续修正。今天有效的方法可能并不适合所有环境，当前的判断也可能在下一次实验后被推翻。我更愿意把限制讲清楚，而不是让每篇文章都显得毫无波折。
这个网站因此不是一份已经完成的作品集。它会跟着我的项目一起变化，留下我如何思考、如何犯错，又如何把问题一点点弄明白的痕迹。