浏览器只认第一个带selected属性的option，后续均忽略；HTML中selected是布尔属性，JS应操作select.value或selectedIndex而非option.selected，且需注意移动端兼容性与框架水合问题。
select 中多个 option 同时写 selected 会怎样
浏览器只认第一个带 selected 属性的 option，后面的全部忽略。哪怕 DOM 里写了十个 selected，实际下拉框默认选中的永远是第一个出现的那个。
常见错误现象：后端模板循环渲染 option 时，用条件判断给匹配项加 selected="selected"，但没 break 或控制唯一性，导致 HTML 里多个 option 都带了该属性——此时视觉上仍只显示第一个被选中，容易误以为逻辑没生效。
- HTML 层面
selected是布尔属性，写即为 true，不区分selected、selected=""或selected="selected" - JS 动态设置时，应操作
select.value或select.selectedIndex，而不是反复增删selected属性 - 服务端渲染时，确保只有一个
option包含selected属性，建议用 if/else 而非多 if 并列判断
JS 修改 select 默认选中项的正确方式
直接改 option.selected 属性在部分旧版 IE 或某些 Shadow DOM 场景下可能不同步触发 change 事件或 UI 更新；更可靠的是操作 select 元素自身。
使用场景：表单初始化、搜索条件回填、联动下拉更新后重置选中状态。
立即学习“前端免费学习笔记（深入）”；
- 设值优先用
select.value = "xxx"（推荐），自动匹配option[value="xxx"]并选中 - 按索引选中用
select.selectedIndex = 2，注意索引从 0 开始，-1 表示无选中 - 避免
option.selected = true后不触发重绘的情况，尤其在 Vue/React 的非响应式 DOM 操作中 - 如果 value 值含空格或特殊字符，确保
option的value属性已显式声明，不要依赖 textContent 回退匹配
selected 属性与 select.value 不一致时会发生什么
HTML 解析阶段，浏览器根据 selected 属性决定初始选中项；之后 JS 修改 select.value 会覆盖它。但若 JS 只改了某个 option.selected，而没触发改 select 的状态，就可能出现「DOM 属性和实际选中值不一致」的隐性 bug。
典型错误现象：用 querySelector('option[selected]') 找到的元素，和 select.selectedOptions[0] 返回的不是同一个节点；或者序列化表单时取 select.value 得到的是旧值。
-
select.selectedOptions始终反映当前真实选中状态，比查selected属性可靠 -
select.value是只读 getter（大部分情况），赋值才生效；读取时返回当前选中option的value，无选中则为空字符串 - SSR 页面 hydrate 时，React/Vue 若未同步 initial value 和 DOM 的
selected，会导致水合警告或行为错乱
移动端 select 在 iOS Safari 中的 selected 兼容细节
iOS Safari 对 selected 属性的解析更严格：如果 option 没有显式 value，且 textContent 包含换行或首尾空格，select.value 可能读不到预期值，进而影响默认选中逻辑。
性能影响不大，但兼容性问题往往在真机测试阶段才暴露，且难以复现于桌面模拟器。
- 所有
option必须带明确的value属性，不要省略或留空 - 避免在
option内写 HTML 实体或富文本，iOS 对<br>等处理不稳定 - 动态插入
option后，需手动触发select.value = select.value强制刷新 UI（仅 iOS 15–16 某些版本需要） - 使用
new Event('change', { bubbles: true })派发事件时，iOS Safari 可能不响应，优先用select.dispatchEvent()配合setTimeout延迟执行
真正麻烦的不是怎么写 selected，而是当它和 JS、框架、移动端交织在一起时，哪个环节悄悄覆盖了你的意图。检查顺序、显式 value、少依赖 DOM 属性读取，比死磕语法更能避开坑。
