结论：需用scene()方法显式指定场景，如validate()->scene('edit')->check($data)，否则默认走空场景；场景名大小写敏感，字段必须在对应场景中显式声明，且验证器为单例，跨请求可能残留上一次场景状态。
ThinkPHP 的 Validate 怎么按场景分组验证？
直接说结论：用 scene 方法定义分组，再用 scene() 指定校验入口，不是靠传参或配置文件自动切换。
很多人以为写几个 scene 方法就完事了，结果调用时还是全量校验——根本没生效。关键在「调用时必须显式指定场景」，否则默认走空场景（即全部规则）。
-
scene是链式方法，只负责注册分组规则，不改变默认行为 - 必须配合
validate()->scene('edit')->check($data)这种写法才真正启用分组 - 场景名是字符串，大小写敏感，
'update'和'Update'是两个不同场景 - 一个字段在多个场景里规则不同，得在每个
scene()里单独重写，不能“继承+覆盖”
为什么 scene('create') 调用后仍报登录字段缺失？
常见错误是字段没在对应场景里声明。比如用户表单有 username、password、email，但 create 场景只写了 username 和 email，漏掉 password，而验证器默认把所有字段当必填——其实不是“必填”，是它根本没在该场景里定义，导致校验逻辑跳过该字段，但后续业务代码又去取 $data['password']，于是报错。
- 每个场景必须显式列出该场景下涉及的所有字段，哪怕规则和默认一样也要写一遍
- 字段未出现在当前场景的规则数组中 → 不参与校验 → 也不保证存在 → 后续代码取值可能出 Notice 或 Fatal
- 推荐做法：先定义完整规则数组，再用
only()或remove()精确控制字段范围，比手写更安全
验证器里 scene 和 rule 的执行顺序影响什么？
顺序直接影响字段是否被纳入校验流程。rule 是基础规则池，scene 是从池子里捞出子集并可能改写规则。如果先调 scene('edit') 再调 rule()，新规则不会进当前场景；反之，先 rule() 再 scene()，场景才能基于最新规则构建。
- 推荐写法：先写完整
rule，再集中写所有scene，避免遗漏 -
scene内部调用only()会清空其他字段规则，append()则是在现有基础上追加 - 动态修改规则（如根据参数开关某条验证）不适合放
scene里，应改用闭包验证或自定义验证方法
多层控制器调用时，scene 分组容易被意外覆盖吗？
会。ThinkPHP 验证器是单例，一旦你在 A 控制器里调了 validate()->scene('api')，紧接着 B 控制器没指定场景就直接 check()，它会沿用上一次的 scene 设置——这是最隐蔽的坑。
- 每次调用前必须明确指定
scene()，不要依赖“上次状态” - 别在构造函数或
initialize()里预设scene，那等于给整个实例埋雷 - 复杂业务建议封装一个校验方法，如
checkForCreate($data)，内部固定调用scene('create')，避免散落各处的手动调用
场景分组本身不难，难的是意识不到验证器状态是跨请求残留的。很多人调试半天发现是上个接口污染了当前验证上下文。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
