直接修改 wp_options 表的 theme_mods_XXX 项不可行，因主题自定义头部代码通常不存于此，硬改易破坏序列化结构致白屏；应先查主题源码确认存储逻辑，或用 mu-plugin 安全注入。
直接改 wp_options 表的 theme_mods_XXX 项行不通
wordpress 的自定义头部（custom header）代码——比如你从「外观 → 自定义 → 额外 css」或某些主题的「header code」字段里填的内容——通常不存进数据库的某个固定字段，而是由主题自己决定怎么存。很多主题压根不存数据库，只存在 php 模板里；少数主题会用 update_option('mytheme_header_code', ...) 这类自定义 option，但绝不是统一写在 theme_mods_xxx 里。
常见错误是翻出 phpmyadmin 直接搜 theme_mods，发现里面一堆序列化数据，硬改完刷新没生效，甚至导致自定义面板白屏——因为序列化字符串被破坏，unserialize() 失败后整个 get_theme_mod() 调用链就崩了。
先确认主题是否真把头部代码存进数据库
打开你当前主题的 functions.php 或设置页面对应的 PHP 文件，搜索这几个关键词：add_theme_support('custom-header')、get_theme_mod、header_code、custom_js、before_head。如果完全没找到任何和「头部插入」「 里加代码」相关的逻辑，那基本可以确定：这个主题根本不支持数据库存头部代码，你填的那些内容可能只是前端 JS 动态注入，或者压根没实现持久化。
真正会存库的主题一般会有类似这样的代码：
update_option('mytheme_custom_header', $user_input); // 注意：key 名完全由主题定，不是标准字段
所以第一步永远不是连数据库，而是看主题源码。否则你在 phpMyAdmin 里瞎改，改的可能是另一个功能的字段，或者根本不存在的 key。
手动插入前必须校验序列化结构（如果主题真用了 theme_mods）
极少数主题会把头部代码塞进 theme_mods_XXX 的某个子键里，比如 custom_header_html。这时候不能直接 UPDATE 字段值，必须保持 PHP 序列化格式完整：
- 用
SELECT option_value FROM wp_options WHERE option_name = 'theme_mods_twentytwentyfour';取出原始值 - 用 PHP 的
unserialize()解析（别用在线反序列化工具，容易出错），确认结构里是否有你要的键 - 修改数组后，用
serialize()重新生成字符串——注意：PHP 8.1+ 对浮点数、引用等序列化行为有变化，本地 PHP 版本要跟 WordPress 运行环境一致 - UPDATE 时确保
option_value字段类型是longtext，且字符集是utf8mb4，否则中文或 emoji 会导致 unserialize 失败
漏掉任意一步，轻则新值不生效，重则整个「自定义」页面打不开，后台报错 Warning: unserialize(): Error at offset X of Y bytes。
更安全的替代方案：用 wp_insert_post() 或插件方式绕过主题限制
如果你只是想让某段代码（比如统计脚本、SEO meta）稳定出现在所有页面 中，又不想动主题、也不敢碰数据库，其实有更可控的做法：
- 新建一个 mu-plugin（
wp-content/mu-plugins/header-inject.php），里面写：add_action('wp_head', function() { echo '<script>console.log("injected");</script>'; }, 999); - 或者用
wp_insert_post()创建一篇状态为publish、post_type为wp_block的隐藏文章，再通过钩子读取它的post_content——适合需要后台编辑权限的运营人员 - 避免用
wp_enqueue_script(..., array(), ..., true)往wp_head插 JS，因为true表示放footer，放错位置可能触发 CSP 报错或执行时机不对
数据库不是万能接口，尤其对 WordPress 这种靠 hook 和 option 机制驱动的系统。手动改库最危险的不是改错字段，而是改对了字段却破坏了数据完整性约束——比如某个主题依赖 option_value 的长度做缓存键，你多了一个空格，它就全失效了。
