本地攒过很多源码、模板、脚手架和资料快照以后，最大的问题不是“东西不够”，而是下次想用时不知道哪个还能用、哪个只是历史线索、哪个碰一下就会把旧配置和脏文件带回来。
源码快照最好先当索引管理，而不是直接当项目管理。索引要回答四个问题：它是什么、适合查什么、当前放在哪里、真正复用前要先做哪些验证。
先分清快照和主线项目
快照只是某个时间点的本地留存。它可能包含旧依赖、旧构建方式、临时配置、未提交改动，甚至已经失效的远端地址。主线项目则应该有 README、构建命令、验证命令和明确维护边界。
所以第一次整理时，不要急着把所有源码搬进主项目。先把它们按博客模板、导航站、后台管理、文档站、Java 样例、爬虫代理、数据集这类用途分组。真正要复用时，再重新拉取远端或寻找当前维护版本。
每个条目都要有风险边界
参考源码里经常混着账号配置、Cookie、采集目标、代理设置、本机路径和旧日志。公开文章或正式项目不应该直接复制这些内容。索引里只保留用途和验证动作，敏感配置留在本机私有配置或归档说明里。
一个条目至少写清楚：
- 快照名称和大概类型。
- 适合查视觉、架构、接口、部署还是某个工具用法。
- 是否有远端仓库或当前维护版本。
- 复用前需要检查许可证、依赖版本、构建命令和最近提交。
- 是否包含账号、采集、代理或历史脏文件线索。
不要让索引变成第二个垃圾堆
索引不是把路径再贴一遍。低价值空快照、纯分支记录、纯机械 Git 状态可以进入清理候选；带配置、dirty-files 或自有改动线索的目录先保留说明，不要直接删。
更稳妥的做法是：索引负责找得到，正式专题负责讲清楚，项目 README 负责跑得起来。三层分开以后，本地资料不会越整理越乱。
以后再遇到“以前好像存过一个类似项目”，先查索引；决定要用，再进入项目实践。这样既保留记忆线索，也不会把旧包袱拖进新工程。
正文完
