直接写死select嵌套行不通，因省市区数据量大导致维护难、体积膨胀、加载慢，且纯HTML无法响应选择变化实现三级联动；需JavaScript动态控制DOM、disabled状态及数据填充，并注意状态同步与兼容性问题。
为什么直接写死 select 嵌套行不通
因为省市区数据量大（全国约34个省级、300+地级、2800+县级单位），硬编码在HTML里不仅维护困难，还会让页面体积膨胀、加载变慢。更关键的是，用户选择“广东省”后，第二级 select 必须实时清空并填入21个地级市——这只能靠 JavaScript 控制 DOM，纯 HTML 无法响应变化。
select 的 disabled 和 innerHTML 配合逻辑
三级联动本质是“前一级选完，后一级才可操作 + 内容重置”。常见错误是只清空 innerHTML 却忘了设 disabled="true"，导致用户提前点第三级，选了无效值。
- 第一级
select初始化后保持启用，其他两级默认加disabled - 监听第一级的
change事件，用fetch或本地 JSON 获取对应地级市列表，清空第二级innerHTML后插入option，再移除其disabled - 第二级同理：选完后请求县级数据，填入第三级并启用它
- 每次重置下级时，记得先
select.value = ""，否则旧值可能残留
用 JSON 数据结构决定前端解析方式
后端返回的数据格式直接影响 JS 处理逻辑。如果接口返回扁平数组：[{"code":"110000","name":"北京市","level":1},{"code":"110100","name":"市辖区","level":2}]，就得靠 code 前两位匹配省级、前四位匹配地级——容易出错且性能差。更稳妥的是分层结构：
{
"province": [
{
"code": "110000",
"name": "北京市",
"cities": [
{
"code": "110100",
"name": "市辖区",
"areas": ["东城区", "西城区", "..."]
}
]
}
]
}
这样前端可直接用 province[0].cities 填第二级，cities[0].areas 填第三级，避免字符串截取和循环查找。
立即学习“前端免费学习笔记（深入）”；
移动端 select 的兼容性坑
iOS Safari 对 select 的样式控制极弱，且原生下拉菜单体验割裂；安卓部分 WebView 会忽略 disabled 状态。实际项目中更推荐用 div + scroll 模拟三级弹层（如使用 van-picker 或 nut-picker），但若必须用原生 select：
- 给每个
select加aria-label提升无障碍支持 - 禁用
user-select: none，否则 iOS 上无法触发下拉 - 第三级首次加载后，调用
select.focus()让键盘不意外弹出 - 别依赖
select.selectedIndex === 0判断是否未选——用户可能手动删掉默认空选项
真正麻烦的不是怎么填数据，而是处理“用户退回上一级时，下级要同步清空 + 禁用 + 重置提示文案”。这个状态管理稍有遗漏，就会出现“选了广东深圳，再切回北京，第三级还显示深圳的区”。
