直接在<td>中嵌套<select>合法，但需注意CSS样式冲突、name属性缺失、事件精准绑定及移动端系统选择器适配等边界问题。
直接在 <td> 里放 <select> 就行，但得注意表单语义和样式冲突
HTML 表格单元格本身不排斥表单控件，<select> 可以合法嵌套在 <td> 或 <th> 中。真正容易出问题的是 CSS 默认样式（比如 border-collapse、padding）和表格布局对控件尺寸的挤压。
常见错误现象：<select> 被截断、下拉箭头消失、点击无响应、选项文字被遮挡。
- 确保父级
<td>没有设置overflow: hidden或过小的height - 给
<select>显式设置width: 100%（否则可能只占内容宽度，不撑满单元格） - 避免在表格上全局设置
table-layout: fixed后又没给列宽，会导致<select>挤压变形
<select> 的 name 和 value 必须按需设置，否则筛选逻辑无法触发
单纯渲染下拉菜单没用，关键是要让它的选择能被 JS 读取或提交到后端。很多开发者漏掉 name 属性，导致表单提交时该字段根本不出现在 FormData 里。
使用场景：如果是纯前端筛选（比如过滤表格行），value 决定筛选条件；如果是提交表单，则 name 是后端接收的键名。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
<select name="status">—— 提交时字段名为status - 每个
<option value="active">启用</option>的value应该是程序可处理的标识，而非中文文本 - 初始选中项建议用
<option selected value="all">全部</option>，别依赖 JS 动态设值，避免闪屏
多个 <select> 共存时，事件监听要绑定到具体元素，别用委托踩坑
表格里每行一个 <select> 很常见，但用事件委托（比如监听 tbody 的 change）容易拿错目标行——因为 event.target 是 <select>，而你需要的是它所在的 <tr>。手动遍历绑定更稳。
性能影响：100 行以内直接循环绑定 addEventListener 完全没问题；超 500 行才考虑委托，但必须用 closest('tr') 精准定位。
- 推荐写法：
document.querySelectorAll('td select').forEach(sel => { sel.addEventListener('change', e => { const row = e.target.closest('tr'); console.log('第', row.rowIndex, '行选了', e.target.value); }); }); - 别写
document.querySelector('table').addEventListener('change', ...)—— 表格本身不触发change，事件会冒泡但目标难追溯
移动端点开下拉菜单时，表格滚动和键盘弹出容易互相干扰
iOS Safari 和部分安卓浏览器中，<select> 原生下拉会强制唤起系统选择器，此时页面可能被推高、滚动位置丢失，甚至卡住。这不是代码 bug，而是浏览器行为。
兼容性影响：桌面端几乎无感，但移动端必须测试真机。别指望 position: absolute 或 z-index 能覆盖系统选择器——它在独立图层。
- 缓解方案：给表格容器加
min-height: 300px，避免视口高度剧烈变化 - 如果业务允许，改用自定义下拉（如基于
<details>或 JS 实现），但代价是失去原生无障碍支持 - 务必测试微信内置浏览器，它对
<select>的渲染和 focus 处理最不稳定
<select> 本身很简单，难点全在边界情况：样式挤压、事件溯源、移动端适配。最容易被忽略的是 name 属性缺失和移动端真机测试。 
