重复项目会逼着人把工具抽出来

我不是一开始就喜欢抽工具。早期项目里，最直接的方式通常是把功能写在当前系统里：验证码能发，文件能传，表格能用，WordPress 能优化，证书能申请，先把项目交付掉。

但项目做多以后，重复会变得很刺眼。同样的验证码流程、同样的上传接口、同样的后台表格、同样的编辑器、同样的 WordPress 优化项，如果每次都重新写，最后浪费的不是代码量，而是判断力。

抽包要从重复痛点开始

我更愿意把工具包看成项目被重复摩擦后的结果，而不是技术展示。

短信验证码就是典型例子。阿里云和腾讯云 driver、验证码生成、缓存 TTL、校验后失效、本地环境固定验证码，这些逻辑在不同项目里都会出现。如果每个项目都临时写一遍，容易出现缓存 key 不一致、过期时间不清楚、校验后不删除等细节问题。

抽成 Laravel 包以后，项目只需要关心发送和校验，driver 和缓存规则收在一起。它不复杂，但减少了很多重复决策。

上传功能也很容易被低估。

后台项目里，图片、文件、编辑器附件、远程图片都可能进入系统。如果只按原文件名保存，重复上传、文件覆盖、路径混乱和编辑器格式都会变成后续问题。我在上传包里更关注 hash 去重、按日期分目录、媒体元数据记录，以及输出编辑器可以直接使用的结构。

这类工具的价值不是“上传文件”四个字，而是让不同项目对文件进入系统的方式保持一致。

WordPress 项目里也有一批重复动作：关闭评论、emoji、pingback、XML-RPC，清理 head 噪音，处理上传行为，替换国内访问较慢的资源，优化用户和后台体验。

这些改动如果散落在主题函数里，后面很难维护。抽成插件以后，站点定制和站点优化可以分开。主题负责表达，插件负责运行习惯。

这也是我后来做 WordPress 定制时更明确的边界：不要把所有东西都塞进主题。能独立成为运行策略的东西，应该有自己的位置。

React 组件库里，表格、表单、树、标签、触发器、编辑器、PDF 预览这些东西，看起来都是 UI。

但我真正想抽的不是颜色和样式，而是交互规则。表格要处理查询状态、URL 同步和批量操作；表单要处理弹窗触发、校验和提交；编辑器要处理上传端点、内容块和渲染；PDF 查看器要处理远程文件、工具栏和页面高度。

这些能力如果在每个后台里散写，后面每个项目都会长出一套自己的小规则。组件库的意义，是让重复规则收敛。

抽出来不代表一劳永逸。

Laravel 版本会变，React 组件库会换，WordPress API 会更新，业务项目的形态也会变。有些旧包现在看已经不适合直接继续用，但它们仍然有价值，因为它们留下了当时的边界判断。

我现在对工具沉淀的看法更克制：不是所有重复都值得抽，也不是抽出来就要强行复用。真正值得保留的，是那些能减少项目不确定性的能力。它们让下一个项目少踩一次坑，也让工程经验不只停留在某个代码仓库里。