WordPress时区需优先设timezone_string（如"Asia/Shanghai"），若设gmt_offset则必须清空timezone_string；语言应改wp_options表的locale选项而非WPLANG常量；siteurl和home须同步更新；修改后必须清空对象缓存、OPcache及浏览器缓存。
wp_options 表里改 timezone_string 和 gmt_offset 会冲突
wordpress 同时支持两种时区设置方式：用 timezone_string（如 "asia/shanghai"）或用 gmt_offset（如 8.0）。但数据库里这两个值不能随意共存——如果 timezone_string 非空，wordpress 就忽略 gmt_offset；反之，如果 timezone_string 是空字符串或 null，才会 fallback 到 gmt_offset。
常见错误是只改了 gmt_offset 却没清空 timezone_string，结果页面时间还是不对。实操建议如下：
- 优先用
timezone_string，它更精确（能自动处理夏令时），设为"Asia/Shanghai"或"Europe/London"等标准 IANA 时区名 - 如果非要手动设偏移量，先执行
UPDATE wp_options SET option_value = '' WHERE option_name = 'timezone_string';，再更新gmt_offset - 修改后务必清空对象缓存（如 Redis、Memcached）和 PHP OPcache，否则后台看到的时区可能仍是旧值
语言设置不是改 WPLANG 常量，而是改 locale 选项
很多人在 wp-config.php 里加 define('WPLANG', 'zh_CN');，但这只是早期兼容写法，从 WordPress 4.0 起已废弃。真正起作用的是数据库 wp_options 表里的 locale 选项（注意不是 WPLANG）。
典型问题：改了 WPLANG 没生效，或者多站点下子站语言不随主站同步。实操要点：
- 直接执行
UPDATE wp_options SET option_value = 'zh_CN' WHERE option_name = 'locale';（中文简体）或'ja'（日语）等 ISO 639-1 语言码 - 插件或主题的语言包是否加载，还取决于
WP_LANG_DIR路径和load_theme_textdomain()调用，光改locale不保证所有文字都变 - 多站点环境下，每个站点有自己的
locale选项，需逐个更新，网络级设置无效
批量替换站点 URL 时，siteurl 和 home 必须同时改
换域名或迁移到 HTTPS 后，仅改 siteurl 不够，home 也得同步。否则后台能进，前台首页跳转 404 或重定向循环——因为 home 控制前端入口地址，siteurl 控制后台和资源路径。
容易踩的坑是用 REPLACE 直接扫整个数据库，结果把文章内容里的链接也误改了。安全做法是：
- 只更新
wp_options表中option_name IN ('siteurl', 'home')的两条记录 - 用
UPDATE wp_options SET option_value = REPLACE(option_value, 'http://old.com', 'https://new.com') WHERE option_name IN ('siteurl', 'home'); - 改完立刻检查
wp-admin/options-general.php页面，确认两个字段显示正确，且“保存更改”按钮不报错
修改后前台时间/语言没变？别忘了 wp_cache_flush() 和浏览器缓存
WordPress 默认启用对象缓存（即使没装 Redis），get_option('locale') 和 get_option('timezone_string') 结果会被缓存。数据库改了，PHP 层可能还在读旧值。
最常被忽略的环节是缓存清理顺序：
- 先在 wp-admin > 工具 > 状态 > 信息页点“刷新对象缓存”，或用 WP-CLI 执行
wp cache flush - 如果用了 OPcache，需重启 PHP-FPM 或执行
opcache_reset()（部分主机不开放） - 浏览器强制刷新（Ctrl+Shift+R），尤其 Chrome 对 304 缓存很激进，可能卡住旧的
wp-includes/languages/JS 文件
时区和语言这类全局配置，一旦缓存没清干净，调试半天都看不出变化。
