input[type="color"]仅适合简单场景：点选纯色、不需透明度、不苛求体验；真要上生产，Safari≤15.3、iOS WebView、MIUI 13等环境会静默失效或降级为文本框；正确检测方式是document.createElement('input').type === 'color'，返回true才算真正支持。
input[type="color"] 能用，但只适合“点一下选个纯色、不挑体验、不 care 透明度”的简单场景；真要进表单、上生产、接设计系统，它大概率会在 Safari ≤15.3、iOS WebView、MIUI 13 等环境里静默失效或回退成黑块甚至文本框。
怎么检测浏览器是否真正支持 input[type="color"]
别信 navigator.userAgent——很多 WebView 会伪造 Chrome 字样，但实际不支持。正确检测方式只有一行：
const isColorSupported = document.createElement('input').type === 'color';
返回 true 才算真支持。Safari ≤15.3、EMUI 12、MIUI 13 内置浏览器都会返回 false 或直接忽略该 type，渲染成 type="text"，甚至留白。
- 检测必须在 DOM 加载后执行，不能放在
<head>中提前判断 - 服务端 SSR 渲染时无法执行 JS，需配合 UA 特征 + 客户端二次校验
- 检测通过 ≠ 行为一致：Safari ≥15.4 支持
change，但input事件仍不触发（拖拽滑块无响应）
input[type="color"] 的 value 格式极其敏感
它只接受标准 7 位小写十六进制（"#ff6b35"），其他一律静默 fallback 到 "#000000"。常见翻车点：
立即学习“前端免费学习笔记（深入）”；
- 传了
"rgb(255,107,53)"、"var(--primary)"、"blue"→ 黑色 - 服务端返回缩写
"#abc"，没补全成"#aabbcc"→ 黑色 - localStorage 里存的是
"#ff6b35cc"（带 alpha），读出来被截断 →"#ff6b35"，但用户以为能调透明度 - 初始没设
value，input.value默认就是"#000000"，不是空字符串
监听颜色变化该用 input 还是 change？
必须同时绑定两个事件，不能只靠一个：
-
input：拖拽滑块、在色环上移动取色点时实时触发，适合做预览、同步到<div>背景或 canvas -
change：只在用户点击“确定”或失焦后触发，适合做最终保存、提交校验 - 只绑
change→ 拖着滑块不动，UI 完全不更新，用户以为卡了 - 只绑
input→ 用户改完又反悔，点了“取消”，你却已经把中间值存进状态了
怎么让外观可控又不丢原生能力
核心思路：藏掉原生 input，用自定义元素触发它。这样既保住了系统调色板的兼容性与无障碍支持，又能完全控制尺寸、圆角、边框、暗色模式适配：
- CSS 隐藏
input：#picker { position: absolute; opacity: 0; pointer-events: none; } - HTML 结构用
<label for="picker"><div class="color-preview"></div></label>，点击div就等于点input - 别用
display: none或visibility: hidden—— 屏幕阅读器会跳过，键盘 Tab 也聚焦不到 - 移动端需加
touch-action: manipulation防止 300ms 延迟
真正麻烦的从来不是画一个色盘，而是处理 Safari 的 input 事件失效、安卓定制 WebView 对 type 的静默降级，以及 value 格式校验链路上每一个看似微小却会导致整条流程崩掉的细节。
