联动下拉框校验需为每个select维护独立布尔状态，用.value===""或.selectedindex===0判断未选，禁用时移除required，启用后动态添加，校验延至dom更新后执行，服务端必须复核三级路径合法性。
联动下拉框的校验必须独立追踪每个 select 的状态
不能靠 onchange 触发次数（比如“触发三次就认为选完了”），因为用户可能反复切换同一个下拉框，其余两个仍为空。正确做法是为每个 select 维护一个布尔状态变量，值变更时设为 true，最后统一检查三者是否全为 true。
常见错误现象：提交时弹出“请将籍贯选择完整”，但用户明明点了省和市，区还没动——这是因为原始代码用 p.match("请选择") 这类字符串匹配，容易被选项文本中的中文字符干扰（比如“请选择”含全角空格或隐藏符号），且无法区分“未选”和“选了但值恰好含该字符串”。
- 用
.value === ""或.selectedIndex === 0判断是否仍为默认项，更可靠 - 默认
<option></option>应设value=""并加disabled selected，避免被提交 - 校验函数里别直接操作 DOM（如
alert），优先返回布尔值，便于后续扩展（如高亮错误字段）
required 属性对联动下拉框基本无效
给联动的 select 加 required 不起作用：浏览器只校验当前字段是否非空，不关心它是否依赖前序选择。更糟的是，如果第一个下拉框没选，后两个本应禁用（disabled），但 required 会误判它们“未填”，导致校验逻辑混乱。
实际场景中，后两个下拉框初始应为 disabled，仅当前置项有有效值时才启用。此时它们的 required 属性会被忽略（disabled 元素不参与表单校验），所以必须手动控制校验时机。
- 启用后两个
select后，再动态添加required属性（el.setAttribute('required', '')） - 提交前统一调用
checkValidity()，但注意它只对已启用的字段生效 - 别依赖
reportValidity()的原生提示——它不会告诉你“第三个没选是因为第二个没选”，需自定义提示文案
提交前校验要避开 DOM 更新竞态
联动下拉框常配合 JS 动态填充选项（如选省后生成市列表），这时用户点击某个 <option></option>，浏览器可能先触发 change，再更新 value。若校验逻辑紧接在事件回调里执行，可能拿到旧值。
典型表现：用户选完三级，点提交却提示“请选择”，刷新页面再看 value 才发现其实已更新。这是因为校验发生在 DOM 渲染完成前。
- 用
setTimeout(() => { /* 校验 */ }, 0)把校验推到下一轮事件循环，确保 DOM 已同步 - 或者监听
input事件（比change更早触发），但需注意它在键盘输入时也触发，不适合纯下拉场景 - 更稳妥的方式：在校验函数里直接读
document.getElementById('pro').value等实时值，而非缓存的变量
服务端必须重复校验联动关系
前端联动校验只是体验优化，完全不可信。用户可以禁用 JS、手动修改 DOM、用 curl 提交任意值，甚至跳过前两级直接提交第三级的 value（比如传 area=外滩 但 city 是空或非法值）。
后端收到数据后，不能只判断字段是否存在，必须验证三级值是否构成合法路径。例如：上海→黄埔→外滩 是合法组合；但上海→南京→外滩 就该拒绝。
- 数据库或配置中应存有完整的树形结构（如 JSON 或关系表），校验时查路径是否存在
- 不要用字符串拼接做校验（如
if (city + '-' + area in validPairs)），易受注入或编码影响 - 错误响应应明确指出哪一级不合法（如 “城市‘南京’不属于省份‘上海’”），而非笼统返回“参数错误”
真正麻烦的不是怎么写校验逻辑，而是联动层级变多（比如四级行政区+街道）时，状态管理容易散落在各处。建议把所有联动规则收口到一个纯函数里，输入当前各级 value，输出下一级可选项数组和是否允许提交——这样前后端能共用同一套规则定义。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
