中文学习记录博客https://tianzhaoaixuexi.cn/zh_CNhttps://tianzhaoaixuexi.cn/posts/learning-system/https://tianzhaoaixuexi.cn/posts/learning-system/比起偶尔高强度输出，更重要的是把记录动作设计成容易重复的流程。Thu, 23 Apr 2026 00:00:00 GMT<p>学习记录最容易失败的地方，不是不会写，而是流程太重。每次都要想“写在哪、怎么分类、怎么发布”，动作就会被拖慢。</p> <h2>我给自己定的三个原则</h2> <h3>1. 先记事实，再提炼方法</h3> <p>先把问题、上下文和结果写下来，之后再抽象成经验。这样更真实，也更容易积累材料。</p> <h3>2. 入口固定</h3> <p>只保留一个写作入口，比如 Markdown 文件夹，不在多个工具之间切换。</p> <h3>3. 发布动作足够短</h3> <p>如果一次发布需要很多手工步骤，记录就会中断。最好压缩成一条命令，写完就能发。</p> <h2>这篇之后的动作</h2> <p>接下来我会继续把技术问题、阅读摘录和阶段总结都放进同一套结构里，让内容能被时间和主题两条线索同时找到。</p> https://tianzhaoaixuexi.cn/posts/frontend-debugging/https://tianzhaoaixuexi.cn/posts/frontend-debugging/从报错信息、依赖差异到最终修复，把一次构建问题拆成可复用的排查步骤。Tue, 21 Apr 2026 00:00:00 GMT<p>最近在整理一个旧项目时，构建阶段突然开始报错。第一反应通常是“依赖坏了”，但真正有效的方法是把问题拆小。</p> <h2>我先做了什么</h2> <ol> <li>先保留原始报错，不急着改配置。</li> <li>确认是开发环境能跑，还是只有生产构建失败。</li> <li>对比最近变动：依赖版本、Node 版本、环境变量。</li> </ol> <h2>排查时最有用的动作</h2> <ul> <li>把错误信息抄成可搜索关键词。</li> <li>只改一个变量，然后重新构建。</li> <li>给每一步结论做记录，避免绕回头路。</li> </ul> <h2>这次留下的结论</h2> <p>真正有价值的不是“修好了”，而是形成一套稳定排查路径。下次再遇到类似问题，我会先看输入条件，再看构建链路，不会一上来就盲目重装依赖。</p>