模板改造最怕的不是改得丑，是改完之后没法升级。半年后官方发布安全更新，你一升级，所有修改全被覆盖；不升级，又留着漏洞。这个两难，根源在于改造方式不对。
一、四条基本约定
1. 不改核心文件
官方模板的文件视为"只读"。所有修改通过子主题、钩子、覆盖文件实现。这样升级时只替换父主题，你的改动还在。
2. 样式分层
分三层：变量层（颜色、字号、间距）、组件层（按钮、卡片、表单）、页面层（首页、列表、详情）。改配色只动变量层，不要把颜色写死在组件里。
3. 命名有前缀
自定义的 class、函数、钩子都加项目前缀，比如 klw-。避免和模板或插件冲突。
4. 记录改动
建一个 CHANGELOG.md，每次改动写清日期、文件、原因。三个月后你会感谢自己。
二、目录结构示例
themes/
├── parent-theme/ # 官方主题，不修改
└── child-theme/
├── style.css # 只放变量覆盖和少量补丁
├── functions.php # 钩子、过滤器
├── templates/ # 覆盖的模板文件
│ ├── header.php
│ └── single.php
└── assets/
├── css/extra.css
└── js/extra.js覆盖的原则：只覆盖需要改的文件，其他继承父主题。覆盖越多，升级时越要检查。
三、用钩子代替硬改
大多数 CMS 都提供钩子（action/filter）。能在钩子里加的，就别改模板文件。
// 在文章末尾插入作者信息
add_action('article_after_content', function () {
echo '';
});钩子的好处是：模板更新不影响，逻辑集中在一处，出问题好排查。
四、样式怎么写才不打架
- 用 CSS 变量覆盖主题色，不重写整个选择器。
- 提高选择器优先级要谨慎，尽量用更具体的选择器而不是
!important。 - 新增样式单独放一个文件，按页面分区注释。
- 移动端样式用
@media覆盖，不要重写整套。
五、JavaScript 的边界
模板自带的 JS 不要改。新增交互写成独立文件，用事件委托绑定，避免和主题的事件冲突。
如果必须覆盖某个行为，先解绑再绑定，而不是叠加：
// 先移除主题的处理器，再绑自己的
element.removeEventListener('click', themeHandler);
element.addEventListener('click', myHandler);六、升级前的检查清单
- 备份当前主题和数据库。
- 在测试环境升级，不要直接在生产环境操作。
- 对比升级前后的模板文件差异，看是否影响你覆盖的部分。
- 检查所有页面：首页、列表、详情、表单、404。
- 确认无报错后再上线，保留回滚包。
七、什么情况下值得重写而不是改造
三个信号：改造点超过模板文件的一半；模板已经两年没更新；模板作者不再维护。
这种情况下，继续打补丁的成本会超过重写。重写时把之前积累的组件和规范带过去，反而更快。
不要改核心文件
用子主题、钩子或模板覆盖，把改动集中在自己的目录里。每改一处记一笔，升级时才知道会不会冲突。
直接改核心文件，升级一次就丢一次。规范不是约束，是给未来的自己留退路。
用子主题或模板覆盖，不要直接改核心文件。改动集中在自己目录，升级才不冲突。
常见问题
子主题会不会影响速度
会多一次 CSS 请求，但影响很小。可以把子主题样式合并进主样式表来消除。
没有子主题机制怎么办
用插件化的方式：把改动写成独立插件，通过钩子注入。或者建立自己的模板分支，但要记录所有改动。
改了模板要不要告诉客户
要。交付时给一份改动说明，客户以后找别人维护也能接上。
改造的方向选择，见模板站如何避免同质化。
