WordPress自定义角色调用current_user_can校验权限始终返回false

1. 角色slug大小写不匹配 #

WordPress角色slug为严格大小写敏感。你创建角色时使用的名称是「Expert」，测试代码中get_role()传入的是全小写'expert'，如果创建角色时传入的slug首字母大写，小写调用拿到的并非目标角色，属于残留测试数据的概率极高。
修复操作：

• 核对add_role()第一个参数（角色slug）的准确大小写，所有角色调用、权限判断处的slug必须和创建时完全一致，禁止大小写混用。
• 直接打印当前登录用户的实际权限集合，不要仅查角色配置：

// 临时调试用，验证后立即删除
$current_user = wp_get_current_user();
wp_die(var_export($current_user->allcaps, true));

如果输出结果中不存在manage_zoom_meetings，说明用户权限集合未加载该权限，问题出在角色分配或权限缓存层。

2. 用户权限缓存未刷新 #

WordPress不会每次加载页面都从角色配置重新拉取权限，会将用户全量权限序列化存储在用户元数据{表前缀}capabilities字段中。如果是在用户登录后才给角色新增manage_zoom_meetings权限，已登录用户不会自动同步新权限，必须重建权限缓存。
修复操作：

• 快速验证：受影响用户退出账号后重新登录，登录流程会自动触发权限缓存重建。
• 开发阶段批量刷新：

// 仅执行一次，执行完立刻删除，禁止留存在生产环境
global $wpdb;
$prefix = $wpdb->prefix;
$user_ids = get_users(['fields' => 'ID', 'number' => -1]);
foreach ($user_ids as $uid) {
    wp_cache_delete($uid, 'user_meta');
    $current_caps = get_user_meta($uid, $prefix.'capabilities', true);
    update_user_meta($uid, $prefix.'capabilities', $current_caps);
}

• 给角色新增/修改权限后，主动调用wp_roles()->init_roles()重载角色配置，避免开发阶段缓存干扰。

3. 钩子执行时机错误 #

如果调用current_user_can()的节点早于WordPress权限初始化流程（比如在plugins_loaded之前、functions.php全局空间直接调用），此时角色配置还未加载，判断结果必然为false。
修复操作：

• 所有权限判断、add_menu_page()菜单注册逻辑必须挂载到对应标准钩子：菜单注册挂admin_menu，其他权限判断挂init及之后的钩子。
• 如果权限用于自定义文章类型，注册CPT时必须开启map_meta_cap参数，否则自定义权限无法正常映射，示例配置：

register_post_type('zoom_meeting', [
    'labels' => $labels,
    'show_ui' => true,
    'public' => false,
    'capability_type' => 'zoom_meeting',
    'map_meta_cap' => true, // 该参数缺失会直接导致自定义权限校验失效
    'capabilities' => [
        'manage_options' => 'manage_zoom_meetings',
        // 其余增删改权限按需映射
    ]
]);

验证标准 #

调试输出当前用户allcaps集合存在manage_zoom_meetings => true时，current_user_can()、后台菜单权限控制、自定义文章类型权限校验都会正常生效。

内容的提问来源于stack exchange，提问作者aswiss