直接用select嵌套写死省市区数据会导致加载慢、DOM膨胀、逻辑错误（如选广东后仍显示朝阳区），且无法适配后端按层级返回数据的机制；正确做法是逐级异步加载、清空下级选项、禁用未就绪控件、用dataset标记层级，并优先采用按需加载的JSON数据源。
为什么直接用 select 嵌套写死省市区数据会出问题
因为真实业务里，用户可能先选“北京市”，再选“朝阳区”，但下拉列表里如果把全国所有区都塞进第二个 select，不仅加载慢、DOM 膨胀，而且选了“广东省”之后，“朝阳区”还留在选项里——逻辑就错了。更麻烦的是，后端接口通常只返回当前层级的子集（比如选了“广东”，才请求“广东下的市”），前端必须等上一级选中后再触发下一次请求。
常见错误现象：change 事件没绑定、异步请求没清空下级 select 的 option、选中值没重置导致残留旧选项、没处理加载状态造成重复点击提交。
- 每次上级
select变化时，必须清空所有下级select的innerHTML或调用removeChild - 用
disabled属性临时禁用下级select，避免用户在数据未返回前误操作 - 推荐用
dataset标记每个select的层级，比如<select data-level="province"></select>，比靠 class 或 name 判断更可靠
怎么用 fetch + Promise 链式加载三级数据
不能把三个接口写成同步顺序调用（那样会阻塞 UI），也不能全扔进 Promise.all（第二级依赖第一级 ID）。正确做法是：第一级加载完 → 用户选中 → 触发第二级请求 → 返回后再启用第三级。
关键点在于，每个请求的 URL 都要带上游 ID：/api/cities?province_id=110000，而第三级请求必须等第二级的 value 确实存在才发起。
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
provinceSelect.addEventListener('change', async () => {
citySelect.innerHTML = '<option value="">请选择城市</option>';
districtSelect.innerHTML = '<option value="">请选择区县</option>';
citySelect.disabled = true;
districtSelect.disabled = true;
const pid = provinceSelect.value;
if (!pid) return;
try {
const res = await fetch(`/api/cities?province_id=${pid}`);
const cities = await res.json();
citySelect.innerHTML = '<option value="">请选择城市</option>' +
cities.map(c => `<option value="${c.code}">${c.name}</option>`).join('');
citySelect.disabled = false;
} catch (e) {
console.error('加载城市失败:', e);
}
});
为什么推荐用 JSON 数据源而不是写死 HTML option
写死 HTML 意味着所有省市区数据都打包进首屏 HTML，gzip 后也近 200KB，首屏加载慢、SEO 无意义、更新要改代码。而 JSON 数据源可按需加载，体积小（单个省份的城市平均不到 2KB），且便于国际化或对接不同行政区划标准（比如民政部最新代码 vs 企业自定义编码）。
注意兼容性：JSON 中的 code 字段必须与后端约定一致；若后端返回的是拼音或简称（如 "bj"），前端拼 URL 时得映射回标准码，否则第三级请求会 404。
- 国内常用数据源：国家统计局年度统计用区划代码（注意每年 12 月更新）、高德/腾讯地图 API（需申请 key，有调用量限制）
- 本地开发可先用 mock 数据，例如
mock/provinces.json，但路径别写死，用配置项控制是否走 mock - 如果页面需要支持“搜索+下拉”而非纯 select，
select就不够用了，得换input+ul自实现，那是另一套交互逻辑
移动端适配和无障碍访问容易被忽略的细节
在 iOS Safari 上，原生 select 会唤起系统滚轮控件，但如果不设 appearance: none，样式很难统一；而强行覆盖又可能导致 VoiceOver 读不出选项内容。最稳妥的做法是保留原生 select 结构，只用 CSS 微调字体、高度和边框，不替换 DOM。
无障碍重点：label 必须用 for 关联每个 select；每个 option 的 value 必须有意义（不能是空字符串或序号）；加载中状态要用 aria-busy="true" 和 aria-live="polite" 告知屏幕阅读器。
一个常被跳过的坑：用户从地址簿粘贴“北京市朝阳区建国路8号”，程序没法自动反向匹配三级值。这种场景需要额外加「地址解析」服务，不属于级联选择器本身职责，但产品需求里经常混在一起提。
