原生需严格遵循表单语义：name必须存在且命名准确，selected仅用于默认项，disabled可作用于整体或选项但readonly无效；multiple会改变ui与交互，多选优先用checkbox；样式定制能力弱，强需求应换方案。
原生 <select></select> 完全可以不依赖 JS 正常工作，关键在于属性组合是否符合表单语义和浏览器预期。写错一个属性，就可能提交空值、默认项失效或移动端行为异常。
name 属性必须存在，否则表单不提交
没有 name 的 <select></select> 在表单提交时会被完全忽略，哪怕用户选了值也传不到后端。
-
name是唯一决定字段名的属性，id只用于 DOM 查找或<label for="xxx"></label>关联 - 不要用
name="city[]"之类写法试图“模拟数组”——单选场景下后端收不到数组，只收字符串；真要多选，得配multiple属性 - 如果后端接口要求字段名为
filter_by，那就老老实实写name="filter_by"，别指望 JS 补救
默认选中项必须用 selected，且只能有一个
浏览器只认 selected 这个布尔属性本身，写成 selected="true" 或 selected="selected" 是冗余的，还容易误导人以为它是可开关的。
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
- 多个
<option selected></option>时，仅第一个生效，其余被忽略 - 想设“请选择”为占位提示，但又不让它被提交：用
<option value="" disabled selected>请选择</option>——disabled阻止选择，value=""确保提交时不带脏数据 - 别在 JS 里动态设
select.value = "xxx"后就以为完事了；原生行为下，没用户交互就不会触发change事件，校验逻辑可能漏判
disabled 要分清作用对象：整个控件 or 单个选项
disabled 加在 <select></select> 上，整块灰掉、不可聚焦、不参与表单提交；加在某个 <option></option> 上，仅该项变灰、不可点，其他照常可用。
-
<select disabled></select>会绕过所有键盘导航（Tab 跳过）、屏幕阅读器跳过，无障碍体验断裂；慎用于需要“只读展示”的场景 -
<option disabled></option>在 Safari 中有时不显灰，建议补一句opacity: 0.6或color: #999 -
readonly对<select></select>完全无效，HTML 规范没定义这个行为，写了等于白写
移动端和多选的隐性代价必须提前意识到
加了 multiple 不只是“能多选”，它会彻底改变 UI 形态和交互逻辑，iOS 和 Android 的处理方式也不一致。
-
multiple后，<select></select>渲染成滚动列表，不再是带箭头的下拉框；用户必须按住 Ctrl/Cmd 才能多选，鼠标拖拽无效 - iOS Safari 强制弹出全屏系统选择器，样式完全不可控；Android 各厂商实现差异大，有的显示列表，有的仍走下拉
- 提交时同名参数变成多个（如
hobby=reading&hobby=swimming），后端必须能接收数组格式，PHP 要写name="hobby[]"，Node.js 得用body-parser的 extended 模式 - 如果只是“让用户从一堆里挑一个”，别加
multiple；真要多选，优先考虑<input type="checkbox">组合，更可控
最易被忽略的是：原生 <select></select> 的样式定制能力极弱，尤其是箭头图标、下拉面板宽度、禁用态颜色等，在 Safari 和旧版 Edge 中几乎无法统一。如果设计稿强制要求自定义外观，那就不是“免 JS”的问题了，而是该换方案——比如用 <input> + <datalist></datalist> 做轻量搜索，或引入成熟库，而不是硬改原生元素。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
