button:disabled + filter: grayscale() 经常没反应，因为:disabled仅匹配原生可禁用表单元素且需真实设置disabled属性；div或框架组件不匹配该伪类，ios safari对filter在:disabled元素上渲染不一致，高对比度模式下filter被忽略，且filter不阻止交互、不改语义，必须配合disabled属性、aria-disabled和pointer-events:none等多层控制才能确保禁用状态一致。
button:disabled + filter: grayscale() 为什么经常没反应
因为 :disabled 只匹配原生可禁用的表单元素（<button></button>、<input>、<select></select>），且必须真实设置 disabled 属性（不是 disabled="false"，也不是自定义属性 disabled="true"）。如果你用的是 <div> 或 Vue/React 封装的按钮组件，<code>button:disabled 根本不会生效——它连选择器都匹配不到。
更隐蔽的问题是：某些浏览器（尤其是 iOS Safari）对 filter 在 :disabled 元素上的渲染支持不一致，可能样式挂载了但视觉无变化，或切换时闪烁。打开 DevTools 手动删掉 disabled 属性，看灰度是否同步消失，这是验证是否真由该伪类控制的最快方式。
filter: grayscale() 的写法和兼容性取舍
单独写 filter: grayscale(1) 在 Safari 旧版本（iOS 12–14）里容易过暗甚至全黑；在高对比度模式（@media (forced-colors: active)）下，filter 会被系统强制忽略，导致禁用态“看起来还能点”。
稳妥做法是组合使用：
-
filter: grayscale(100%) brightness(0.92);—— 避免 Safari 下文字发灰发糊 - 同时显式定义
color和background-color，比如color: #999; background-color: #f5f5f5;，确保高对比度模式下仍有明确视觉反馈 - 加
transition: filter 0.15s ease;，否则快速启停时滤镜会跳变 - 绝对不要用
filter: blur()或drop-shadow()，低端安卓 WebView 渲染掉帧明显
为什么不能只靠 filter 做禁用状态
filter 只改外观，不改语义也不拦交互。用户仍能用 Tab 键聚焦、屏幕阅读器仍播报“按钮”，键盘按回车还会触发事件——这属于典型的“视觉禁用，行为未禁用”。
真正可靠的禁用必须三者同步：
- DOM 层：
disabled属性（表单控件）或aria-disabled="true"（非表单元素） - CSS 层：
button:disabled或自定义 class（如.btn--disabled），并配cursor: not-allowed - 行为层：JS 中显式检查
if (el.disabled) return;，或用pointer-events: none（注意：它会同时禁用焦点，仅适合纯触摸场景）
React/Vue 中动态禁用按钮的样式陷阱
框架里常写 <button :disabled="isSubmitting"></button> 或 <button disabled></button>，但 DOM 属性更新和 CSS 重绘之间可能有微小延迟，尤其在异步请求刚结束时。用户看到按钮已“启用”，点一下却没反应——其实是 disabled 属性还没被移除，样式却先刷新了。
更可控的做法：
- Vue：用
v-bind:class="{ 'btn--disabled': isDisabled }"主动控制 class，再配合:disabled="isDisabled"确保语义 - React：避免直接绑定
disabled={isSubmitting}后又手动操作 DOM，优先用 state 控制 class + 属性双写 - 测试时别只看鼠标，一定要按 Tab 键确认焦点是否真的跳过该按钮
灰度只是禁用状态的第一层表达，漏掉语义或交互控制，用户就会遇到“看着像不能点，结果点了有反应”或者“读屏器说能点，但点不动”的情况。真正难的不是让按钮变灰，而是让所有通道（视觉、键盘、语音、触控）对“不可用”达成一致理解。
