接手第一步：先摸清现状，再动手
接手存量站点，第一件必须做的事不是看代码，而是建立一份改动前快照：完整文件备份 + 数据库导出 + 记录当前的插件/主题版本号。这份快照既是回滚依据，也是判断“问题是否由本次改动引入”的对照基线。
第二步是列出改动清单：站点正在使用哪些主题与插件、哪些是官方原版、哪些已被前手改过。区分“原版”与“改过”的方式通常是版本号与文件的修改时间比对，必要时与官方版本做逐文件 diff。
八个高频坑与规避动作
- 不备份就动手。直接在生产环境改文件，出错后无基可退。规避：改动前必须完成文件与数据库双备份，并在本地或测试环境先行验证。
- 直接修改父主题。父主题一升级，所有自定义改动被覆盖。规避：一律通过子主题承载改动。
- 在插件源码上打补丁。插件更新即丢失，且升级后行为不一致。规避：优先使用插件提供的钩子或过滤器扩展，确需改动时用独立插件覆盖其行为。
- 全局搜索替换改样式或文案。看似高效，实则误伤同名变量、函数与字符串。规避：改动限定在明确文件内，替换前先预览匹配结果，逐项确认。
- 忽略环境差异。本地与线上 PHP 版本、数据库版本、启用的扩展不一致，导致“本地正常、线上报错”。规避：改动前核对两端环境参数，并把环境要求写进交接文档。
- 忽略缓存层。改完看不到效果，误判为改动失败，进而重复修改。规避：明确站点是否启用页面缓存、对象缓存与 CDN，改动后按既定流程清缓存再验证。
- 未评估影响面就改结构。修改数据库字段、内容类型或公共钩子，牵动大量既有页面。规避：先检索该结构被引用的位置，列出受影响清单，再决定改动方式。
- 没有改动记录与回滚方案。改动完成后无人知道改了什么、为什么改。规避：每次改动都记录文件、原因与影响范围，重要改动配套回滚步骤。
如何建立可持续的二次开发规范
单个坑可以靠细心避免，但持续交付要靠规范。几条可落地的约定：
- 改动收敛：所有自定义逻辑集中在子主题与自研插件中，形成“可识别的自有代码区”；
- 版本留痕：用版本管理工具承载代码，提交信息写清改动目的，而非只写“修改”；
- 升级预演：主题或插件升级前，先在测试环境验证自定义部分是否仍生效；
- 交接文档：记录环境参数、插件清单、已做改动与已知问题，让下一位接手者不必重新考古。
小结
二次开发的本质是“在一个不完全了解的系统中做有边界的改动”。先备份、再评估、后动手，把改动限制在自有代码区并留下记录，绝大部分坑都可以提前规避。技术上的难点通常可控，不可见的历史改动才是真正的风险来源。