创建WordPress子主题，先在父主题旁边建立独立目录，用style.css文件头声明主题名称和父主题目录，安装并启用后，再加入确实需要的样式或模板定制。子主题保存自己的修改，父主题继续提供基础功能；父主题更新不会直接覆盖子主题文件，但仍需要检查两者是否兼容。
本文用Twenty Twenty-Four作为明确示例，子主题目录叫young-child，演示给一个段落加局部样式。换用其他父主题时，要先检查它怎样加载CSS，不能把示例当作所有主题通用的安装包。基本机制与该父主题示例见WordPress子主题指南。
哪些修改值得放进子主题
仅换Logo、改导航或调整主题已有颜色时，先用现成设置入口。子主题更适合需要随文件保存和交接的主题定制，例如修改某个模板或维护少量展示样式；与外观无关的业务功能，则不应因为换主题而消失。
| 需求 | 优先考虑的方式 | 判断依据 |
|---|---|---|
| 改站点标志、默认字体或颜色 | 主题设置、站点编辑器 | 已有入口能完成，运营者容易维护 |
| 为少数元素加CSS | 附加CSS，或有文件管理需求时用子主题 | 看规模、版本管理与交接方式 |
| 修改现有模板结构 | 子主题对应模板 | 避免直接改父主题文件 |
| 保存询盘、提供业务接口 | 合适插件或独立功能实现 | 功能不应依赖某个主题继续启用 |
| 大量重写主题结构 | 重新评估开发方案 | 覆盖越多，后续比较与维护越多 |
先结合WordPress主题与模板分工决定文件归属。子主题是一种隔离定制的方式，不会自动检查代码安全，也不会自动把父主题新修复合并进你覆盖的旧模板。
动手前准备测试站、文件与数据库备份，以及后台打不开时可用的主机文件工具。现有网站从父主题切到子主题，还需核对菜单、主题选项和后台定制是否按预期延续，不能把切换当作完全无影响的操作。
先创建最小目录和style.css
确认Twenty Twenty-Four已安装，父主题文件夹为twentytwentyfour。在主题目录中创建与它同级的young-child，不要把子主题嵌套进父主题内部。
wp-content/themes/
├── twentytwentyfour/
│ └── 父主题原有文件
└── young-child/
└── style.css
在young-child/style.css中写入文件头：
/*
Theme Name: YOUNG Child
Template: twentytwentyfour
Version: 1.0.0
Text Domain: young-child
*/
Theme Name是后台显示名称；Template必须准确对应父主题文件夹名，不是显示名或下载地址。Version用于自己的版本记录，Text Domain与翻译标识有关。文件头的作用和字段定义见WordPress主样式表说明。
这是本地试验的最小结构，不是准备分发的完整产品说明。此时不用先建立空functions.php，也不用复制全部父主题模板。若以后分发，还需补齐适用的作者、许可及资源信息。
保存文件时确认扩展名确实是.css，不是Windows隐藏扩展名后形成的style.css.txt。目录名也保持一致；在大小写敏感的服务器上，拼写差异可能导致找不到父主题。
安装启用后，先验证继承，再增加代码
将young-child目录压缩为ZIP，包内保留young-child/style.css的结构，在测试站“外观 → 主题 → 添加新主题 → 上传主题”安装。也可以通过已授权的文件工具把该目录放到测试站主题目录；选择一种部署方式即可。
启用YOUNG Child后，在主题列表确认当前对象，并保留父主题。打开首页和一篇文章，检查基础显示、菜单与已有内容。没有添加定制时，外观与父主题大致相同是正常结果，不能为了“证明子主题生效”立即复制几十个文件。
提示缺少父主题时，核对Template、父目录与安装完整性；主题完全没有被识别时，检查包的嵌套层级、style.css名称和文件头。先解决识别问题，再加样式，避免把安装错误与CSS错误混在一起。
CSS怎样加载，先看父主题实际做了什么
style.css有文件头，说明WordPress能识别主题，并不代表里面的CSS一定被输出到前台。区块主题可能主要通过theme.json处理样式，经典主题也有不同的资源加载方式。
先查看父主题文档与加载代码，再在测试页检查浏览器Network（网络）面板里的CSS请求。若存在合并压缩插件，测试环境可暂时排除合并干扰，避免仅因看不到独立文件请求就误判未加载。相关机制见WordPress资源加载说明。
如果独立的 style.css 请求被优化工具合并了，先到聚合文件里查测试规则。需要区分精简、合并和延迟加载时，按CSS/JS压缩与加载检查处理，不要因为请求名称变了就重复加载一份样式。
| 已确认的父主题行为 | 子主题需要做什么 |
|---|---|
| 父主题已加载自己的资源和子主题style.css | 不重复添加第二套加载代码 |
| 父主题只加载自己的样式 | 按需要单独加载子主题CSS，并确认正确顺序 |
| 父主题使用活动主题样式地址，切换后只读到子主题CSS | 核对是否还需要补加载父主题原资源 |
| 区块主题主要通过theme.json提供样式 | 不为文件头强行加载无实际规则的style.css；有自定义CSS时再处理 |
判断依据是具体文件和注册代码。父主题的主要CSS可能并不叫style.css；样式标识（handle）也不等于目录名称。不了解这些值时，不要把网上的“parent-style”当成实际存在的依赖名。
给Twenty Twenty-Four子主题加一个局部样式
在本文这个示例中，按官方子主题文档的方式单独加载子主题style.css。在young-child目录新增functions.php，放入以下代码。它用于前台样式加载，不是文章正文中的代码片段，也不应追加到父主题文件。
<?php
add_action( 'wp_enqueue_scripts', 'young_child_enqueue_styles' );
function young_child_enqueue_styles() {
wp_enqueue_style(
'young-child-style',
get_stylesheet_uri(),
array(),
wp_get_theme()->get( 'Version' )
);
}
get_stylesheet_uri()指向当前启用主题的style.css，因此启用子主题后指向young-child/style.css，详见函数文档。最后的版本参数取自子主题文件头；以后修改CSS时同步更新自己的版本号，便于资源缓存区分版本。
这段示例没有额外加载父主题style.css。其他父主题若要求子样式在某个父样式之后加载，应把实际父样式handle放入依赖数组，并确认它已注册。参数含义见wp_enqueue_style文档。不能把父主题目录名直接填进去碰运气。
新建一个测试页面，插入普通段落，在区块高级设置中填写CSS类名young-child-note；类名字段不带前面的点。然后在style.css文件头之后加入：
.young-child-note {
border-left: 4px solid #2563eb;
padding-left: 1rem;
}
发布测试页并查看前台。预期只有带该类的段落出现左侧蓝线和留白，其他普通段落不变。代码文件使用正常文本格式保存；PHP文件以开头标记开始，避免在它前面留无关输出，纯PHP文件不需要补结束标记。
这一步的目标是验证一个明确元素，不是用全站背景变色或大范围覆盖来证明代码运行。测试成功后，可保留确实有用的样式，或删除测试规则和测试页面。
做到这里，最终文件关系应当是这样。functions.php 是刚增加的子主题文件，里面只保留这次需要的加载代码：
wp-content/themes/
├── twentytwentyfour/ 父主题，保持原文件
└── young-child/
├── style.css 主题声明和局部CSS
└── functions.php 本例的子样式加载函数
留下一行测试记录即可：测试页URL｜启用young-child｜样式来源URL｜带类段落出现蓝线｜普通段落不变｜手机正常。哪一项没过，就沿下一节对应的现象找原因；这份记录也方便把文件交给下一位维护者。
没看到变化时，按请求、匹配和覆盖检查
不要一开始就给CSS加!important。它不能解决文件没加载、地址404或类名拼错，只会让后续层级更复杂。
| 观察到的结果 | 可能问题 | 下一步 |
|---|---|---|
| 没有子主题CSS请求，也没在聚合资源中找到规则 | 加载函数未执行或资源配置不完整 | 核对当前启用主题、函数文件和钩子 |
| 请求返回404 | 路径、文件名或部署位置不正确 | 比对实际文件位置与请求URL |
| CSS正常返回，但没有测试规则 | 部署文件或缓存版本不对 | 打开响应内容，核对版本和最新规则 |
| 规则存在，但目标元素没有该类 | 类名未保存或放错对象 | 在元素面板确认class属性 |
| 规则匹配但被划掉 | 其他样式覆盖 | 查看生效规则的来源，按局部范围调整 |
| 前台有样式，编辑器里没有 | 前台和编辑器加载位置不同 | 按需要另配编辑器样式，不能当作前台失败 |
例如网络面板显示style.css为200，但打开响应只看到文件头，说明文件被加载了，却没有你以为已经上传的规则。此时应该修正部署内容或缓存，而不是重写enqueue函数。若规则存在且被另一条边框设置覆盖，则继续追查具体样式来源。
确认修复后，复查测试段落和一个不应变化的普通段落，再检查手机宽度。这样同时知道目标生效和影响范围没有扩大。
模板可以覆盖，functions.php不能照搬父文件
只复制确实需要改的模板，并保留相对路径。例如区块父主题使用templates/single.html，子主题可以放同路径文件；经典主题可能使用single.php。两种结构各按实际父主题处理，不把PHP和区块HTML模板互相替换。
假设只是调整文章底部作者区域，就记录为什么覆盖这个模板、修改了哪一段，并检查两篇文章。不必把所有未改模板一起复制，否则以后父主题更新时，这些旧副本也可能继续挡住新实现。
functions.php的机制不同：父子两份都会加载，子主题先于父主题。把父文件整份复制到子主题，容易产生同名函数冲突。新增函数使用自己的前缀，并在适当钩子执行；依赖父函数时还要确认调用时机，不能在父函数尚未加载时直接调用。来源：WordPress主题函数说明。
文件路径函数也要按目标选择。读取子主题资源与明确读取父主题资源不是同一件事；例如get_template_directory_uri()在子主题场景指向父主题目录，不能用它去寻找只放在子主题里的图片。相关定义见该函数文档。
区块主题：数据库定制可能优先于文件
你改了子主题模板文件，前台却仍是旧布局，除了路径和缓存，还要检查站点编辑器是否保存过同一模板的定制。WordPress会优先考虑用户保存的模板，再按子主题与父主题提供的文件查找。来源：WordPress模板加载说明。
先保存或导出当前定制，再决定是否重置目标模板来使用文件版本。不要为了验证single.html，清除全站所有模板和样式。若定制正由运营人员维护，继续保留数据库版本也可以，但要把来源记录清楚。
颜色、字体与布局等全局设置也可通过theme.json管理，并与父主题及用户定制形成层级关系。它适合需要随主题文件交付的设置；单个站点的日常调整，站点编辑器可能已经够用。机制见theme.json介绍。
把子主题搬到另一个站点时，文件夹里没有包含的数据库定制不会自动跟过去。交付前分别列出主题文件、后台模板、全局样式和必要插件设置，再按相应方式导出或迁移；不要只凭当前站显示正常就认定ZIP已经完整。
父主题更新后，检查你覆盖的那部分
父主题不会覆盖子主题文件，这是子主题的优势；也正因为如此，子主题里复制的旧模板不会自动得到父模板的新修改。父主题更新了作者区域结构或修复某个输出问题，你仍覆盖旧single模板时，就要比较差异并决定怎样保留定制和吸收修复。
可维护一份简短记录：
| 自定义对象 | 保存目的 | 更新后复查 |
|---|---|---|
| style.css中的局部规则 | 特定提示段落样式 | 类名仍存在，规则不误伤其他块 |
| functions.php加载函数 | 加载子主题CSS | 文件只按计划加载，日志无新增相关错误 |
| 覆盖的single模板 | 修改文章底部展示 | 对比父模板新版本，复查动态内容和结构 |
| 后台定制模板 | 当前站点独有布局 | 明确它仍优先生效，迁移时另外导出 |
测试顺序是先验证基础继承，再一次加入一项定制，最后测试文章、导航、手机布局、表单和后台编辑。父主题有新版本时，在测试副本更新并复查覆盖范围，不只检查首页能打开。
新增functions.php后出现严重错误，先通过预留的文件工具恢复该文件上一版，或在可用条件下回切父主题，恢复访问后根据报错检查语法、重名和调用时机。不要继续追加代码。数据与恢复准备可沿用WordPress备份与恢复。
正式部署时使用已验证的同一份文件及必要配置，再检查关键入口。保留上一个可用版本和定制记录，后续从WordPress建站知识库继续对应维护工作。
常见问题
子主题一定要有functions.php吗？
不一定。最小识别需要带必要文件头的style.css；需要加载资源或添加函数时才增加functions.php。CSS是否已被父主题加载，要检查实际行为，不能按文件是否存在猜测。
启用子主题以后，可以删除父主题吗？
不可以。子主题仍依赖父主题的模板、功能和资源。启用子主题是保存定制的方式，不是把父主题完整复制替代。
为什么CSS在前台生效，后台编辑时却看不到？
前台与编辑器的样式加载可能不同。先确认前台目标和范围正确；若需要编辑器同步显示，再按主题支持方式配置编辑器样式，不必为此重复加载前台CSS。
AI生成的子主题代码可以直接部署吗？
先核对父主题、文件位置、API、函数名和加载条件，再在测试站验证实际效果。尤其检查重复函数、重复样式与错误模板覆盖。生成代码不能替代恢复准备、代码审阅和业务验收。