WordPress 表前缀修改需同步更新 $table_prefix、插件兼容性、Laravel 模型配置及数据库权限；必须停插件扫描硬编码、显式声明表名与主键、分离数据库连接、限制用户权限粒度，并定期核对。
WordPress 表前缀不能只改 wp_ 还得同步改 $table_prefix 和迁移逻辑
wordpress 默认用 wp_ 做表前缀，但 laravel 也连同一个数据库时，光靠手动改几张表名没用——wp-config.php 里的 $table_prefix 必须匹配实际表名，否则后台进不去、插件查不到数据。更麻烦的是，有些插件（比如 woocommerce）会在安装/激活时硬编码写死前缀，甚至直接执行 create table wp_posts 这类语句。
- 改前缀前先停掉所有 WordPress 插件，尤其是缓存类和数据库优化类
- 用
wp db search "wp_" --all-tables扫一遍，确认没有插件在 SQL 字符串里硬写前缀 - 修改
$table_prefix后必须重新运行wp rewrite structure和wp rewrite flush，否则固定链接 404 - Laravel 迁移里如果要读写
wp_users这类表，别用Schema::create()，改用DB::statement("ALTER TABLE ...")避免 Laravel 自动加前缀
Laravel 模型访问 WordPress 表时，protected $table 必须显式声明且禁用时间戳
WordPress 表结构和 Laravel 约定差异很大：wp_users 没有 created_at/updated_at，主键叫 ID 而不是 id，字符串字段多是 utf8mb4_unicode_ci 但 Laravel 默认用 utf8mb4_general_ci。不处理这些，模型一查就报错或漏数据。
- 模型里必须写
protected $table = 'wp_users';，不能依赖命名约定 - 加
public $timestamps = false;，否则save()会尝试写不存在的字段 - 主键名不是
id的，得补protected $primaryKey = 'ID';和public $incrementing = false;（如果 ID 是字符串） - 查询时用
DB::connection('wordpress')分离连接，别混用默认连接，避免事务跨系统污染
用户登录态共享最稳妥的方式是绕过 Laravel Auth，直接复用 WordPress 的 wp_set_auth_cookie()
想让 Laravel 登录后 WordPress 也认人，或者反过来，别碰 wp_signon() 或自己解析 wp_users.user_pass —— WordPress 密码是 salted hash，Laravel 的 Hash::check() 解不开；而直接调用 WordPress 函数又得加载整个 WP 环境，容易和 Laravel 的自动加载冲突。
- 在 Laravel 登录成功后，用
exec("php /path/to/wp-load.php --user-login {$userId}")异步触发 WP 设置 cookie（注意路径权限） - 更稳的做法：Laravel 登录后，重定向到一个轻量 PHP 脚本（如
/wp-auth-sync.php），里面只 requirewp-load.php，然后调用wp_set_auth_cookie()，最后跳回 Laravel 页面 - 千万别在 Laravel 中 include
wp-load.php，PHP 的__autoload和 Composer 的 autoloader 会打架，常见错误是Class 'WP_Query' not found
数据库用户权限必须按表粒度隔离，GRANT SELECT ON wordpress.wp_options 比 GRANT ALL ON wordpress.* 少踩 80% 的坑
两个系统共库，权限放太宽等于给 Laravel 开了删 wp_options 的门——某个迁移手抖写了 Schema::dropAllTables()，或者某次 php artisan migrate:refresh 误连到生产库，wp_options 一丢，整个站点设置全崩。
- 为 Laravel 单独建数据库用户，只给
SELECT, INSERT, UPDATE, DELETE权限，且仅限laravel_%前缀的表（如laravel_users、laravel_jobs） - WordPress 用户只保留
SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX，但限定在wp_%表，禁止对laravel_%表有任何操作 - 用
SHOW GRANTS FOR 'laravel_user'@'localhost';定期核对，尤其上线新迁移后，防止php artisan migrate自动创建表时用了默认用户 - 备份脚本里明确指定
--ignore-table=wordpress.wp_options等敏感表，避免恢复时覆盖
表前缀和权限不是设一次就完事的事，每次加插件、跑迁移、切环境都得重新对一遍。最常被忽略的是插件更新——它可能悄悄新建一张 wp_wc_custom_table，但没在权限列表里，Laravel 就读不了；或者新建了 wp_laravel_cache，结果 WordPress 插件以为这是自己的表，给清空了。
