\_except 必须作为 route::resource() 的第三个参数传入，仅对资源路由本身生效；若混用闭包、手动定义路由或写错动作名（如用 destroy 而非 delete），则不生效。
资源路由里 _except 不生效？检查是否混用了闭包定义
ThinkPHP 的资源路由（Route::resource()）默认生成 7 个标准动作，_except 和 _only 是用来筛选这些动作的「白名单/黑名单」，但它们只对资源路由本身起作用——如果你在定义时顺手加了闭包或手动指定了 method，那 _except 就完全被绕过了。
-
_except必须作为Route::resource()的第三个参数（数组）传入，不能写在闭包路由里 - 常见错误：先写
Route::resource('user', 'UserController')，再单独补一条Route::get('user/create', ...)—— 后者不受_except约束 - 资源路由内部用的是 HTTP 方法 + 路径匹配，不是靠函数名判断是否该排除；所以
_except => ['create']是去掉GET /user/create这条规则，不是禁用create()方法本身
_only 和 _except 参数写法差异：键名必须是动作名，不是方法名
ThinkPHP 资源路由的动作名（action name）和控制器方法名并不总是一一对应。比如 index 动作对应 index()，但 show 动作对应的是 read()（V6.0+ 默认），而 destroy 对应 delete()。你填在 _only 或 _except 里的，是动作名，不是方法名。
- 标准动作名列表：
index、create、save、read、edit、update、delete - 错误写法：
_except => ['deleteAction']或_except => ['destroy']（后者是 Laravel 风格，TP 不认） - 正确写法：
_except => ['delete']表示不注册DELETE /user/:id这条路由 - 如果改过资源映射（比如通过
Route::resource()->setActionName()），要按你自定义的动作名来写
排除 create 和 edit 后，表单页面还能访问吗？
能，但得看你怎么暴露页面入口。资源路由的 create 和 edit 动作本质只是注册了两条 GET 路由：GET /user/create 和 GET /user/:id/edit。用 _except 排除后，这两条路由不会存在，但控制器方法 create() 和 edit() 依然可以被其他路由调用。
- 如果你希望用户完全看不到新增/编辑页，光靠
_except不够，还得确保没有其他路由指向这两个方法 - 典型踩坑：前端菜单链接还写着
/user/create，但路由已不存在 → 返回 404 - 安全建议：若需隐藏功能，最好配合权限控制（如中间件拦截
create方法执行），而不是只靠删路由 - 性能上无影响：
_except是在路由注册阶段过滤，不增加运行时开销
为什么 _except 在多模块或命名空间下容易失效？
因为 Route::resource() 默认按当前模块和命名空间推导控制器路径。如果你在 app\route.php 里跨模块注册资源路由（比如 admin 模块下的 user），但没显式指定完整命名空间，ThinkPHP 可能找不到控制器，导致整个资源路由注册失败——此时 _except 看似写了，其实根本没跑起来。
- 检查方式：执行
php think route:list，确认目标路由是否出现在输出中 - 解决办法：显式传入
['app' => 'admin']或完整控制器类名，例如Route::resource('user', 'app\admin\controller\UserController') - 注意
_except数组必须和资源定义在同一行调用链里，不能拆成两步赋值 - TP 6.1+ 对多应用支持更严格，跨应用资源路由必须用
app\name\route方式加载，否则_except会被忽略
最常被忽略的一点：资源路由的 _except 和 _only 是「静态过滤」，它不感知请求上下文、不支持条件判断。想实现「登录用户可访问 create，游客不可」，得用中间件，别指望靠路由参数搞定。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
