场景验证需动态配置规则集，按请求来源、角色、状态自动切换；验证方法应接收context参数并返回含ruleId和path的结构化错误；支持本地调试注入场景，且需覆盖context边界值。
场景验证规则怎么按不同业务条件动态配置
场景验证不是写死一个 validate() 就完事，核心是让同一套验证逻辑能根据请求来源、用户角色、数据状态自动切换规则。比如后台管理员提交订单不校验短信验证码，但小程序端必须校验；又比如编辑草稿时不校验支付信息，发布时才校验。
实操建议：
- 把验证规则组织成「规则集（rule set）」，每个规则集对应一个明确场景标识，如
"admin_create_order"、"miniapp_submit_order"、"edit_draft" - 入口处用轻量路由/上下文提取场景标签，别硬编码判断
if (req.headers['user-agent'].includes('MiniApp'))—— 这类判断后期难维护、易漏测 - 规则集本身用纯对象定义，避免嵌套函数或闭包，方便单元测试覆盖和 JSON 序列化（比如存到 DB 或配置中心）
验证方法里怎么安全传入动态参数
validate() 方法如果只接受 data 一个参数，就很难适配多场景。真实情况是：你得知道当前用户 ID、当前操作类型、甚至上一步的表单版本号，才能决定要不要跳过某条规则。
实操建议：
- 统一让验证方法接收第二个参数
context，里面只放必要且稳定的字段，如{ userId, role, action, formVersion }，禁止塞 request 对象或整个 session - 规则内部用
context.role === 'admin'而不是context.user?.isAdmin—— 前者类型确定、可静态分析，后者容易因字段缺失抛Cannot read property 'isAdmin' of undefined - 如果某个规则依赖外部服务（如查风控分），把它抽成独立函数，在调用前由上层决定是否执行，别塞进
validate()主流程里拖慢所有场景
为什么 validate() 返回结构必须带 ruleId 和 path
当一个表单有 20 个字段、5 种场景、每种场景启用不同子集规则时，出错后光靠 "手机号格式错误" 是没法定位问题的。前端不知道该标红哪个输入框，日志里也看不出是哪个场景触发了哪条规则失败。
实操建议：
- 每个验证失败项必须返回
{ ruleId: 'mobile_format', path: 'contact.mobile', message: '...' }，path严格匹配数据结构路径（支持嵌套如'items.0.price'） -
ruleId必须全局唯一，不能是中文或拼接字符串，推荐用短横线命名，如"required-field"、"min-length-6" - 不要合并同字段多个错误为一条提示（比如“手机号格式错误且不能为空”），前端需要分别控制展示/隐藏，合并会破坏可访问性和自动化测试断言
本地开发时怎么快速模拟不同场景跑验证
靠手动改接口请求头或反复登录不同账号来测场景验证，效率低还容易漏。真正省时间的方式是让验证模块支持「场景注入」，不依赖真实运行环境。
实操建议：
- 在开发服务器启动时加一个调试端点，如
POST /_debug/validate，允许 POST 带{ data, context, scene }直接触发验证并返回完整结果 - 写几个常用场景的 fixture 文件，如
scenes/admin-submit.json、scenes/user-draft.json，内容就是预设的data和context，方便一键加载 - VS Code 里配个 launch.json，用
curl自动发请求，比切浏览器、填表单快得多 —— 别小看这点，每天省 10 分钟，两周就多出一天调试时间
最常被忽略的是 context 字段的边界值：空字符串、null、0、undefined 都得单独测一遍，它们往往不会报错，但会让规则意外跳过。验证逻辑里对 context 的取值要加防御性判断，而不是默认它“一定有”。
