HTML5仍用和定义下拉列表，无新增专用标签；需name属性提交值，空value占位项须disabled+selected；仅用于input自动补全，非下拉控件；移动端原生样式受限属平台限制。
HTML5 中用
HTML5 没有新增专门的下拉列表标签，仍沿用语义清晰、浏览器支持完善的 元素组合。它不是“新语法”，而是标准用法在 HTML5 文档中继续有效且推荐使用。
核心结构固定： 作为容器，内部用多个 表示可选项， 可选用于分组。
常见错误现象包括：直接写 （内容不会渲染为选项）、忘记 name 属性导致表单提交无值、或误用 （那是输入框的提示建议，不是下拉选择控件）。
-
必须有name属性，否则提交时该字段不会被包含 -
的value值决定提交内容；若省略，则以标签内文本为值 - 默认选中项用
selected布尔属性，如
带占位提示的下拉列表怎么写
原生 不支持 placeholder（因为不是输入框），但可通过一个禁用且不可选的 模拟占位效果。
立即学习“前端免费学习笔记（深入）”；
关键点在于：这个占位项必须同时满足 disabled + selected + hidden（可选），且不能有 value 或设为空字符串，否则可能被提交。
注意：disabled 防止用户选中它；selected 让它初始显示；空 value="" 确保提交时不传无效值。不要只加 selected 而不加 disabled，否则用户还能手动选回去。
是为 提供自动补全建议的机制，行为和视觉都不同于 ：它不阻断输入、不强制选择、不自带下拉箭头，且无法通过键盘方向键完整控制选项。
典型误用场景：想做一个“可选可输”的下拉，却只写了 而没配 ，结果什么也不显示。
正确搭配示例：
这种写法生成的是带下拉建议的文本框，不是传统意义的下拉选择控件。
移动端下拉体验差？这不是 HTML 写法问题
在 iOS Safari 或部分安卓 WebView 中， 会触发系统原生选择器（滚轮式或弹窗式），样式完全不可控——这不是代码写错了，而是平台限制。
如果项目要求统一 UI 或复杂交互（比如多选、搜索过滤、图标支持），原生 就不够用，得用 JavaScript 模拟（如 select2、Choices.js 或自研下拉组件），但要注意：模拟控件需手动处理键盘导航、屏幕阅读器兼容、表单序列化等细节，成本远高于写几个 。
简单表单、后台管理页、对视觉一致性要求不高的场景，坚持用原生 反而是最稳的选择。
