JavaScript 动态填充 select 应直接操作 options 或 innerHTML，先清空再填，正确转义 value 和 text，用 select.value 获取值，避免 iOS 兼容问题，重视数据稳定性与边界处理。
用 JavaScript 动态填充 select 元素内容
直接操作 select 的 options 集合或 innerHTML 是最常用、兼容性最好的方式。不要依赖框架封装的“绑定语法”来处理简单下拉更新，原生写法更可控、出问题时更容易定位。
常见错误现象：select 为空、新选项不显示、旧选项残留、选中状态丢失。
- 先清空再填：每次更新前用
select.innerHTML = ''或循环调用select.remove(0)，避免重复叠加 - 用
option标签字符串拼接时，确保value和显示文本都正确转义（特别是含单/双引号的数据） - 如果数据来自 API，务必在
fetch().then()或axios.get().then()内部操作 DOM，别在请求外直接读取未返回的变量 - 设置默认选中项用
select.value = 'xxx'比select.selectedIndex = 0更可靠，尤其当选项是动态插入且顺序不确定时
响应式联动：第二个下拉菜单依赖第一个的选择
典型场景是“省-市”“分类-子类”。关键不是怎么渲染，而是监听时机和数据匹配逻辑。
容易踩的坑：change 事件没绑定、事件回调里用了闭包导致取到旧值、异步加载时未禁用第二个 select 导致用户误操作。
立即学习“前端免费学习笔记（深入）”；
- 给第一个
select绑定addEventListener('change', handler)，别用onchange = function(){}，后者无法多次绑定 - 在 handler 中先清空第二个
select，再根据event.target.value查找对应子数据（建议用 Map 或对象字面量做预查表，别每次遍历数组） - 如果子数据需请求接口，显示 loading 状态，并把第二个
select.disabled = true，请求成功后再设为false - 注意初始状态：页面加载后，若第一个
select有默认值，应主动触发一次handler来初始化第二个菜单
select 的 value 和 text 不一致时的常见混淆
后端通常只关心 value（比如 ID），但用户看到的是 text（比如名称）。这两者一旦错位，提交表单就会出错。
典型错误现象：表单提交了 ID 却显示名称，或者 JS 里用 select.selectedOptions[0].text 当作值传给后端。
- 永远用
select.value获取提交值，这是标准行为；select.selectedOptions[0].text只用于展示用途 - 生成
option时，确保value属性是唯一、无空格、无特殊字符的标识符（如value="user_123"），别直接塞中文或带空格的字符串 - 调试时快速验证：在控制台输入
document.querySelector('select').value和document.querySelector('select').selectedOptions[0].text对比输出 - 如果后端返回的是 {id: 123, name: "北京"} 这类结构，构造 option 要写成
<option value="123">北京</option>，别把整个对象 JSON.stringify 进 value
移动端 Safari 下拉菜单点击无反应或延迟
这不是 bug，是 Safari 对 select 的原生控件拦截策略导致的——它会阻止某些 JS 在 click 事件中触发 select.click() 或修改 size。
性能与兼容性影响：强行 hack 会破坏可访问性，且 iOS 16+ 后限制更严。
- 放弃用 JS 模拟点击打开下拉（
select.click()在 iOS 上基本无效） - 不要给
select设置size > 1试图让它变列表，移动端会渲染异常 - 如需高度定制样式，用
div+button+ul自建下拉，但必须手动实现键盘导航（Tab/Arrow/Enter）和 ARIA 属性（aria-expanded,aria-controls） - 保持原生
select就是最佳实践：它自带语音朗读支持、触屏放大、滚动惯性，且所有浏览器行为一致
动态下拉真正难的不是怎么加选项，而是数据来源是否稳定、状态是否同步、边界情况有没有覆盖（比如空数组、网络失败、用户快速连点）。这些地方一漏，问题就藏得深，debug 时容易绕远路。
