裸跑可用是渐进式增强的硬性门槛，即去除CSS和JS后页面结构完整、内容可读、表单可提交；语义标签、label绑定、原生交互入口、分层CSS与能力检测均为保障该底线的技术要求。
HTML语义结构必须先于任何CSS或JS存在
裸跑可用不是可选目标，是硬性门槛。去掉所有外部资源后，<nav>里不能是<div>堆砌的菜单，<form>必须带action和method，关键图文不能靠::before伪元素生成。
常见错误现象：用<div class="header">替代<header>；表单控件没<label>绑定；图片缺失alt或写成alt=""却无替代文本。
-
<header>、<nav>、<main>、<article>、<footer>这些标签不是“看起来更规范”的装饰，它们决定屏幕阅读器能否定位、搜索引擎如何理解层级、无样式渲染是否保逻辑流 - 所有交互元素（链接、按钮）必须有真实
href或type="submit"，不能只靠onclick触发JS提交 -
<img>的alt必须传达图像核心信息——图表不能只写“柱状图”，而应写“2024年Q1–Q4销售额：Q1 ￥240万…”
表单控件必须显式绑定label且支持键盘导航
IE11和VoiceOver会跳过未绑定<label>的输入框，键盘用户无法知道当前聚焦的是邮箱还是密码字段。
使用场景：登录页、联系表单、搜索框等任何含<input>、<select>、<textarea>的地方。
立即学习“前端免费学习笔记（深入）”；
- 两种安全绑定方式：
<input id="email">+<label for="email">邮箱地址</label>，或直接包裹：<label>邮箱地址<input name="email"></label> - 禁用
aria-label替代<label>——它绕过原生表单验证逻辑，且部分辅助技术读取不稳定 - 禁用状态的
<button disabled>会自动退出焦点流，此时加tabindex="0"无效
@supports只能用于局部微调，不能控制整页布局
写@supports (display: grid)然后重排整个页面，等于把Safari 12、IE11直接踢出可用范围。真正安全的做法，是只用它调整对齐、间距、圆角精度等不影响DOM流动的属性。
容易踩的坑：@supports (display: grid)单独使用 → Safari 10.1支持grid但不支持gap，卡片间距错乱；嵌套@supports在媒体查询外 → 旧设备也得解析整段CSS。
- 组合检测更稳：
@supports (display: grid) and (gap: 1rem) - 先断点再能力检测：
@media (min-width: 768px) { @supports (container-type: layout) { ... } } - 基础层用
max-width+inline-block+margin实现多栏，确保IE9能正确换行；增强层仅改justify-content、flex-wrap，不改HTML结构
JS只负责锦上添花，不参与核心流程
表单验证、搜索补全、轮播图这些功能一旦JS失效或加载失败，用户就卡住——这不是渐进增强，是功能绑架。
性能影响：不分层会导致旧设备下载并解析大量无用CSS；兼容性影响：某些旧内核遇到不认识的属性会跳过整条规则，甚至阻塞后续解析。
- 所有表单提交必须能通过原生
<form action="/submit" method="post">完成，JS只做防重复提交或异步反馈 - 轮播图默认展示第一张图，其余图用
<picture>或loading="lazy"按需加载，JS仅接管切换逻辑 - 动态内容（如评论列表）必须有服务端渲染的初始HTML，JS只负责增量更新和交互增强
最易被忽略的一点：渐进式增强不是“先写个能跑的HTML，再慢慢加特性”，而是从第一行代码开始就按三层架构约束——HTML定骨架，CSS管外观，JS管行为，三者边界清晰，谁也不越界。否则重构时，你面对的不是增强，而是推倒重来。
