最稳妥方式是用 fieldset + disabled 实现条件禁用，而非单纯 display 切换；需同步控制 required、aria-hidden、tabindex，并始终在服务端校验逻辑依赖。
怎么用 display 切换表单字段显隐最稳妥
直接改 display: none / display: block 是最快的方式，但要注意：它不阻止用户用 DevTools 手动删掉样式、也不校验逻辑依赖。如果字段之间有必填联动（比如选“其他”才弹出输入框），光靠 CSS 隐藏不够，得配合 JS 控制 required 属性和提交校验。
常见错误现象：display: none 的字段仍被表单提交、或者用键盘 Tab 还能聚焦到隐藏项里。
- 始终同步设置
aria-hidden="true"和tabindex="-1"，避免可访问性问题 - 隐藏时记得移除
required，显示时再加回，否则浏览器原生校验会拦住提交 - 别用
visibility: hidden—— 它占布局空间，且 Tab 键仍能进入
用 fieldset + disabled 实现条件禁用比单纯隐藏更安全
当某个字段是否可用取决于另一个选择（比如“是否开具发票”勾选后才启用税号输入），用 disabled 比 display: none 更合理：它天然不提交、不聚焦、不触发校验，语义也更准确。
使用场景：多级联动表单、权限控制下的字段灰化、向导式步骤中未到达的字段。
立即学习“前端免费学习笔记（深入）”；
-
disabled作用于fieldset时，内部所有表单控件都会继承禁用状态 - 注意：
disabled字段值不会出现在FormData或form.elements中，无需手动过滤 - 不要只靠 CSS 灰色样式模拟
disabled—— 用户仍可右键“检查元素”并删掉disabled属性
JS 控制显隐时，为什么推荐监听 change 而不是 click
因为 click 无法捕获键盘操作（空格/回车切换 checkbox/radio）、屏幕阅读器操作、或通过 element.click() 触发的变更；而 change 是表单控件值真正变化后的标准事件。
容易踩的坑：input[type="checkbox"] 在 click 时值还没变，change 才是可靠时机。
- 对
select、radio、checkbox，一律用change - 避免在
change回调里反复查询 DOM —— 提前缓存要控制的字段元素引用 - 如果需要兼容 IE9+，
change在input[type="text"]上不触发即时响应，此时才考虑input事件（但仅限实时搜索类场景）
服务端必须重验条件逻辑，不能信任前端显隐状态
前端控制的显隐只是体验优化，攻击者可以绕过所有 JS 和 CSS，直接 POST 全量字段。比如隐藏的“管理员备注”字段，若服务端没检查“当前用户是否有管理员权限”，就可能被恶意提交。
性能影响几乎为零，但漏掉这步会让整个条件逻辑形同虚设。
- 服务端校验时，别只看字段是否存在，要结合原始请求中的前置条件字段（如
role === "admin"才接受admin_note） - 如果用 JSON API，字段结构本身可能动态变化，服务端应按 schema 做白名单过滤，而非简单
delete隐藏字段 - 前后端条件判断逻辑尽量保持一致（比如都用同一套规则引擎或配置），避免出现“前端显示了，后端却拒收”的错位
条件显隐真正的复杂点不在怎么写 JS，而在于边界情况：用户快速切换选项、初始状态与 URL 参数冲突、服务端渲染与客户端 hydrate 不一致。这些地方一旦忽略，调试起来比写逻辑还花时间。
