WordPress主题设置被重置的主因是wp_options表中theme_mods_*记录被覆盖、删除或autoload设为no，以及主题切换触发自动清理、多站点误操作或PHP版本变更导致反序列化失败。
wp_options表里的theme_mods_*记录被覆盖或删除
WordPress主题设置（比如自定义Logo、背景色、菜单位置）默认不存进主题文件，而是序列化后写入wp_options表，meta_key形如theme_mods_twentytwentyfour（取决于当前启用的主题目录名）。如果你在phpMyAdmin里手动改了其他字段（比如template或stylesheet），但没同步更新对应theme_mods_*行，下次主题切换或保存设置时，WordPress会认为“当前主题没配置”，自动用默认值覆盖——看起来就像“刚改完就重置”。
常见误操作包括：
– 直接清空wp_options表里所有theme_mods_*记录（以为只是缓存）
– 在wp_options中只改了template（父主题）却漏掉stylesheet（子主题），导致主题识别错乱
– 用UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name LIKE 'theme_mods_%'这类语句批量清空，结果把正在用的主题设置也干掉了
wp_options表的autoload字段设为no导致主题设置不加载
wp_options表里每条记录都有autoload字段，值为yes或no。WordPress启动时只预加载autoload = 'yes'的选项；如果theme_mods_*这一行被设成no，它就不会进内存，主题初始化时读不到任何设置，直接 fallback 到默认值。
检查方法：在phpMyAdmin里选中wp_options表 → 点击theme_mods_*那行 → 看autoload列是否为yes。不是的话，手动改成yes再点Go保存。
立即学习“PHP免费学习笔记（深入）”；
注意：autoload = 'no'本身不是错误，有些插件会这么设来减少内存占用，但theme_mods_*必须是yes，否则主题设置永远不生效。
中文 Word 文档自动化校对工具。当用户需要对中文文本或 Word 文档进行标点符号检查、语法检查、错别字检查时使用此 skill。触发词：语法检查、错别字、标点符号、校对、检查文档。
主题切换触发了WordPress的自动清理逻辑
WordPress在切换主题时，会执行switch_theme()函数，其中包含一步：删除旧主题对应的theme_mods_*记录。如果你在phpMyAdmin里手动把template或stylesheet改成了另一个主题，但没真正激活它（比如没进后台点“启用”），WordPress并不知道你“想换主题”，所以不会删记录；可一旦你之后进后台点了一次“保存更改”或“启用新主题”，它就会立刻清掉旧的theme_mods_*，而你之前手动改的设置就没了。
避免方式：
– 不要只改数据库字段来“模拟”主题切换
– 如果真要换主题，先备份wp_options里所有theme_mods_*行（复制SQL INSERT语句）
– 切换后再手动还原对应新主题的theme_mods_*记录，注意把option_name里的主题名同步改掉
多站点（Multisite）环境下修改了错误的wp_options表
WordPress多站点中，每个子站有自己独立的wp_{id}_options表（比如wp_2_options、wp_3_options），而主站用的是wp_sitemeta和wp_options。如果你在phpMyAdmin里看到一堆带数字前缀的表，却误改了主站的wp_options，那子站的主题设置根本不受影响；反之，改了子站的表，主站看起来又“重置”了——其实只是你压根没动对地方。
确认方法：
– 进wp_blogs表查目标站点的blog_id
– 找到对应wp_{blog_id}_options表，再搜theme_mods_*
– 别依赖表名猜测，wp_options只属于主站（ID=1）
最常被忽略的一点：theme_mods_*的value是PHP序列化字符串，里面含主题版本号和时间戳。哪怕你手工复制粘贴，只要前后PHP版本不同（比如从7.4升到8.2），反序列化可能失败，WordPress就当它无效，直接重置。所以别图省事用“编辑”按钮改value，要用INSERT ... ON DUPLICATE KEY UPDATE整行替换。
