技术笔记

这两天开始把 Claude Code 真正用到日常开发里，最大的感受不是“它会不会写代码”，而是它能不能稳定配合我的工作流。我比较在意三件事：能不能快速理解项目结构能不能在不乱改的前提下完成需求能不能把验证步骤一起做完用下来发现，它更像一个执行力很强的协作型工具，而不是一个只会输出答案的聊天框。尤其是在处理小范围样式调整、部署问题、批量替换文案时，效率提升很明显。当然，前提还是要给出明确目标。需求…

最近在写 UniApp 页面时，又一次体会到一个老问题：页面一旦在 H5 和小程序之间切换，布局细节很容易出现偏差。我现在的习惯是：先把页面结构写干净尽量少做复杂嵌套把间距、圆角、字体大小抽成统一变量这样做的好处是，后期调整时不会改一处崩三处。另外，很多页面看起来复杂，其实只是信息分组不清楚。先把内容层级理顺，样式自然就顺了。对我来说，UniApp 最难的从来不是语法，而是“在多个端里保持克制”。

宝塔面板适合我这种想快速上线小项目的人。常见流程其实很固定：1. 建站并绑定目录2. 配置 PHP 版本3. 开启 HTTPS4. 检查伪静态或重写规则5. 设置目录权限真正容易出问题的，往往不是建站本身，而是细节：默认首页文件优先级证书开启后跳转问题上传目录没有写权限配置文件暴露在公网下所以每次部署完，我都会额外做一次“手工点点点”检查。虽然步骤有点笨，但很有效。

很多人一提到博客，就会想到数据库、后台系统、复杂权限。但如果只是做个人博客，文件型方案其实非常舒服。我很喜欢这种结构：文章内容放 Markdown元信息放 frontmatter索引用 JSON 生成优点很直接：迁移方便备份简单不依赖数据库维护成本低尤其是当博客规模还不大时，这种方案比完整 CMS 轻松太多。我越来越觉得，很多个人项目都不需要一开始就上重型架构。

前几天改样式时，明明文件已经更新了，浏览器却一直显示旧页面。后来一看，问题其实很简单：静态资源缓存没有考虑到这个场景。我现在的做法是：图片、字体类资源可以缓存长一点CSS 和 JS 如果经常改，就要考虑版本控制最直接的方式就是加版本号，比如：style.css?v=20260425这样每次改完样式，不用反复怀疑是不是浏览器缓存的问题。这类问题不复杂，但很浪费排查时间，所以记一下。

我慢慢发现，Claude Code 最适合的使用方式不是“一次扔一个大需求”，而是小步快跑。比如把任务拆成：先定位问题再修改一个页面再验证语法最后部署这样做的好处是，每一步都可控。如果直接说“帮我把整个项目做完”，虽然也能推进，但中间更容易出现偏差。说到底，AI 工具并不会替代思路本身，它更适合接住已经明确的目标。

做表单页面最烦的不是控件多，而是状态杂。我现在会尽量遵守几个原则：输入项尽量独立校验规则写清楚提示语不要含糊提交按钮状态要明确特别是在 UniApp 里，如果页面同时兼顾 H5 和小程序，表单交互更要简化。一个看似小的输入页，往往最容易暴露项目整体代码是否整洁。所以表单页其实很锻炼基本功。

站点开启 SSL 之后，我一般会顺手检查下面这些点：HTTP 是否正确跳转到 HTTPS证书是否绑定到正确站点静态资源是否有混合内容警告后台登录页是否还能正常打开有时候证书本身没问题，但跳转规则冲突，会出现循环重定向。这个问题第一次遇到时会觉得麻烦，后面其实就很机械了。部署这件事，本质上就是不断建立自己的检查清单。

做博客时，我以前总觉得导航要放很多东西，后来慢慢反过来了。对个人博客来说，最重要的导航通常就这几项：首页分类搜索关于再多的栏目，很多时候只是增加决策成本。尤其是文章本来就不算特别多时，简单的导航反而更利于阅读。简洁不是少做，而是知道什么不用做。

个人博客后台的登录系统，其实没必要一开始就做得特别重。如果只是自己使用，一个简单的密码校验加 Session 维持登录态，已经足够。重点不是复杂，而是边界清楚：后台路径不要混乱配置文件不要直接暴露登录态过期逻辑要简单明确很多时候，真正的风险不来自“功能太少”，而来自“看起来复杂但细节没守住”。