在WordPress开发中，应检查用户对具体对象的能力，而不是只比较角色字符串。编辑自己的草稿、他人的文章和已发布页面可能需要不同权限；只写“是作者就允许”容易漏掉对象和状态条件。
先明确操作与目标对象
将读取、编辑、发布和删除分开，记录操作的文章ID及内容类型。用户能写新文章，不代表能编辑另一人的已发布内容。自定义文章类型还可能注册不同能力，因此不能把所有对象都按普通文章的角色表推断。
理解元能力的映射
current_user_can支持在edit_post等元能力后传入对象ID，由映射机制结合对象属性检查底层能力。通用edit_posts与具体edit_post不是完全相同的问题。插件还可能过滤能力，判断应发生在实际执行请求中而非只在菜单展示时。
界面隐藏不是权限检查
隐藏编辑按钮可以改善界面，但服务端接口、AJAX动作和批量操作仍需独立检查能力。nonce用于请求来源等保护，也不能代替授权。即使用户看不到入口，也要确保不能通过其他合法请求路径执行未授权动作。
用不同对象建立测试矩阵
在测试站分别核对自己的草稿、他人的草稿、已发布内容和不允许的内容类型，验证允许与拒绝均符合设计。保存具体能力及对象条件，避免以后角色插件调整后靠名称相同继续误判。不要用生产文章执行破坏性试验。
关键区别
角色名称：一组能力的标签；不能覆盖对象条件。
元能力：结合对象作判断；需要正确对象ID。
界面按钮：控制可见入口；不是服务端授权。
怎样确认处理到位
不同作者、状态和内容类型的授权矩阵通过，隐藏入口与服务端判断一致；拒绝操作不会改变目标数据。
容易误判的边界
直接按角色字符串授权不适合复杂站点；应在执行操作时核对当前用户对具体对象的能力。
