本文约 5,448 字，预计阅读 14 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：一个文件，决定站点的安全底线
wp-config.php 是 WordPress 加载的第一个业务文件，数据库凭证在里面，同时它也是唯一可以定义”核心级常量”的地方。
很多提升安全性和性能的操作，其实只是往这个文件里加一行：
define( 'DISALLOW_FILE_EDIT', true );
就这一行，能堵住”后台改主题文件导致站点白屏”和”黑客进后台后直接写后门”这两大类事故。
但绝大多数站长只用过它来填数据库账号，其余常量一概不知。这一篇把值得配的都列出来。
原理分析：wp-config.php 的加载位置与常量生效规则
加载顺序：
index.php → wp-load.php → wp-config.php → wp-settings.php → 核心初始化
关键规则：define() 必须写在 wp-settings.php 被 require 之前，也就是文件里这一行注释之前：
/* That's all, stop editing! Happy publishing. */
require_once ABSPATH . 'wp-settings.php';
写在它之后的常量——要么不生效，要么已经错过了生效时机。最典型的就是 WP_POST_REVISIONS 和 WP_MEMORY_LIMIT，写错位置等于没写。
另外，wp-config.php 可以放在网站根目录的上一级（WordPress 会自动向上查找一级）。这是一个真实的安全加固手段：让配置文件不在 Web 可访问目录里。
/home/user/ ← wp-config.php 放这里
/home/user/public_html/ ← WordPress 其他文件
WordPress 的检测逻辑是：如果根目录没有 wp-config.php，就去上一级找。但注意：上一级目录不能是另一个 WordPress 安装。
保姆级实操
一、安全类常量（建议全部配置）
// 1. 禁用后台的主题/插件文件编辑器（性价比最高的一条）
define( 'DISALLOW_FILE_EDIT', true );
// 2. 禁用后台的插件/主题安装与更新（客户站点强烈建议）
define( 'DISALLOW_FILE_MODS', true );
// 3. 强制后台与登录页走 HTTPS
define( 'FORCE_SSL_ADMIN', true );
// 4. 自动更新策略：只自动更新小版本（推荐）
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
// 其他可选：true（全部自动更新，含大版本）、false（完全关闭）
// 5. 禁止 WordPress 向外发起的文件修改（很少用，但能挡一类后门）
// define( 'DISALLOW_FILE_MODS', true );
// 6. 关闭 XML-RPC
// 注意：这个常量在部分版本不生效，推荐用过滤器 add_filter('xmlrpc_enabled','__return_false')
// define( 'XMLRPC_ENABLED', false );
关于 DISALLOW_FILE_MODS 的取舍：开了之后后台不能装插件也不能更新，适合交付给客户的生产站点；开发期不要开。
二、性能与资源类常量
// 内存限制（前台 / 后台）
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
// 修订版本数量（必须写在 wp-settings.php 之前）
define( 'WP_POST_REVISIONS', 5 ); // 或 false 完全关闭
// 自动保存间隔（秒）
define( 'AUTOSAVE_INTERVAL', 120 );
// 回收站清空周期（天）
define( 'EMPTY_TRASH_DAYS', 15 ); // 设 0 表示禁用回收站
// 关闭 wp-cron 的页面触发（必须同时配系统 crontab！）
// define( 'DISABLE_WP_CRON', true );
// 图片编辑的压缩质量
define( 'WP_EDITOR_DISABLE', false );
EMPTY_TRASH_DAYS 设成 0 要谨慎——删文章直接永久删除，没有反悔机会。
三、调试与日志类常量
// 开启调试模式
define( 'WP_DEBUG', true );
// 写入 wp-content/debug.log（生产环境务必配 WP_DEBUG_DISPLAY=false）
define( 'WP_DEBUG_LOG', true );
// 不在页面显示错误（生产环境调试时必开）
define( 'WP_DEBUG_DISPLAY', false );
// 记录数据库查询（性能排查用，只在调试时开）
define( 'SAVEQUERIES', true );
// 脚本调试：加载未压缩的 JS/CSS（排查 JS 问题时用）
define( 'SCRIPT_DEBUG', true );
// 自定义日志路径
define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );
生产环境排查问题的推荐组合：
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // 关键：不让访客看到报错
@ini_set( 'display_errors', 0 );
这样错误写进 wp-content/debug.log，前台照常显示友好页面。
注意：debug.log 会记录完整路径和错误信息，排查完记得关掉或删除，不要长期开着（日志文件会很大，且泄露路径信息）。
四、路径与 URL 类常量
// 覆盖数据库里的站点地址（改域名救急用）
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );
// 移动 wp-content 目录
define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/my-content' );
define( 'WP_CONTENT_URL', 'https://example.com/my-content' );
// 移动插件目录
define( 'WP_PLUGIN_DIR', dirname( __FILE__ ) . '/my-content/plugins' );
define( 'WP_PLUGIN_URL', 'https://example.com/my-content/plugins' );
// 自定义上传目录
define( 'UPLOADS', 'wp-content/my-uploads' );
WP_HOME / WP_SITEURL 加了之后，后台 设置 → 常规 里的两个地址框会变灰不可编辑，这是预期行为（详见 WordPress 地址与站点地址区别）。
五、数据库与缓存类常量
// 数据库字符集（老站迁移可能需要）
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );
// 数据库表修复模式（只在需要时临时开启，用完必须删！）
// define( 'WP_ALLOW_REPAIR', true );
// 启用对象缓存（配合 Redis/Memcached 插件）
define( 'WP_CACHE', true );
// 启用缓存（部分缓存插件需要）
define( 'WP_CACHE_KEY_SALT', 'example.com' );
WP_ALLOW_REPAIR 开启后访问 /wp-admin/maint/repair.php 能修复数据表，但这个页面无需登录即可访问，用完必须立刻删除这一行。
六、多站点常量
define( 'WP_ALLOW_MULTISITE', true );
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false ); // false=子目录，true=子域名
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
七、环境类型（WordPress 5.5+）
define( 'WP_ENVIRONMENT_TYPE', 'production' ); // production | staging | local | development
设成 local / development 时，WordPress 会放宽一些限制（比如允许 HTTP 下使用应用密码），并在后台显示环境提示。
八、文件权限保护
// 如果 WordPress 无法自动写文件，可以强制用 FTP 方式（不推荐，优先修权限）
// define( 'FS_METHOD', 'direct' ); // 直接写文件（推荐配合正确的属主使用）
FS_METHOD 设成 direct 能解决”提示需要 FTP 凭据”的问题，但前提是 PHP 进程对目录有写权限。
九、验证常量是否生效
wp config list --fields=name,value | grep -Ei "debug|memory|revision|cron"
wp eval 'echo WP_MEMORY_LIMIT, " / ", (defined("DISALLOW_FILE_EDIT") && DISALLOW_FILE_EDIT) ? "edit-off" : "edit-on", "\n";'
常见踩坑与失败案例
- 案例一：
WP_POST_REVISIONS写在wp-config.php文件最末尾（在require wp-settings.php之后），完全没生效，数据库继续膨胀。 - 案例二：生产环境开了
WP_DEBUG_DISPLAY = true，前台把数据库路径、插件路径全暴露给访客。生产环境调试必须WP_DEBUG_DISPLAY = false。 WP_ALLOW_REPAIR忘了删：这个页面无需认证，任何人都能访问并操作数据库。用完立刻删。- 案例三：加了
DISABLE_WP_CRON却没配系统 crontab，定时发布全部失效（详见 wp-cron 定时任务原理）。 WP_MEMORY_LIMIT设太大：超过了 PHP 本身的memory_limit也没用。要在 php.ini 里同步调整。- 移动
wp-content目录后插件全部失效：WP_CONTENT_DIR和WP_CONTENT_URL必须同时改，且很多插件硬编码了wp-content路径。非必要不要动。 DB_COLLATE乱填：留空让 WordPress 自动处理。填错会导致建表失败。- wp-config.php 权限太宽松：应设为 600 或 640：
bash
chmod 600 wp-config.php
总结
wp-config.php 里最值得配的常量按性价比排序：DISALLOW_FILE_EDIT（堵住后台写文件这个最大缺口）、FORCE_SSL_ADMIN、WP_AUTO_UPDATE_CORE = minor、WP_POST_REVISIONS（控制数据库膨胀）、WP_DEBUG + WP_DEBUG_LOG + WP_DEBUG_DISPLAY=false（安全调试三件套）。所有 define() 必须写在 /* That's all, stop editing! */ 之前，写错位置等于白写。进阶加固可以把 wp-config.php 上移一级目录并设 600 权限。三个高危项要注意：WP_ALLOW_REPAIR 用完必删、DISABLE_WP_CRON 必须配套系统 crontab、生产环境绝不能开 WP_DEBUG_DISPLAY。
