合法十六进制颜色代码需用^#([0-9A-Fa-f]{3}|[0-9A-Fa-f]{6})$校验，^和$锚定首尾防误匹配，支持#FF0（3位）和#123456（6位），拒绝#1234567等非法长度。
怎么用正则判断 #FF0 和 #123456 是合法的
必须锚定首尾，否则 #123 会从 abc#123def 中被误判为合法。核心正则就是：^#([0-9A-Fa-f]{3}|[0-9A-Fa-f]{6})$
说明：^ 和 $ 是关键，缺一不可；{3} 匹配简写（如 #fff），{6} 匹配完整格式（如 #ffffff）；| 表示“或”，不是“和”
常见错误：
- 写成
^#[0-9A-Fa-f]+$→ 会接受#1、#1234567等非法长度 - 漏掉
^或$→"xyz#abc123"也会通过校验 - 用
i标志代替显式写A-Fa-f→ 某些旧环境（如部分嵌入式 JS 引擎）不支持标志位
input type="color" 的 value 为什么总校验失败
因为它的 value 永远是小写 7 位格式（如 #ff6b35），而你写的正则可能在匹配大写或带空格的输入。但更常踩的坑是：你根本没在监听正确的事件。
立即学习“前端免费学习笔记（深入）”；
input type="color" 只在用户确认选择后触发 change，拖拽过程中的实时值要用 input 事件捕获——但注意，这个事件返回的仍是标准 #rrggbb 格式，不会出现 #rgb 缩写或命名色。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
所以校验逻辑应统一走同一套正则，且建议在取值后先 .trim().toLowerCase() 再匹配，避免空格或大小写干扰。
服务端传来的颜色值怎么预处理才不崩
后端可能返回 rgb(255,107,53)、#ff6b35、FF6B35、甚至 blue，这些都不能直接塞进 <input type="color" value="...">。
前端必须做三件事：
- 拒绝非十六进制字符串：用
/^#([0-9A-Fa-f]{3}|[0-9A-Fa-f]{6})$/i先过滤 - 补全为 7 位小写：若匹配到 4 位（如
#rgb），要展开为#rrggbb；若无#，手动加上 - 转小写并 padStart：确保最终是
#rrggbb格式，例如"#FF6B35".toLowerCase().padStart(7, '#')（其实padStart在这里只是保险，因为合法值已是 7 位）
为什么 iOS Safari 上颜色控件显示为空白
这是真实存在的兼容性断层：iOS Safari 15.4 之前完全不支持 input type="color"；15.4+ 虽支持，但若你加了 appearance: none 或其他重置样式的 CSS，它会直接失效并显示为空白框。
解决方案不是硬扛，而是检测 + 降级：
- 用
document.createElement('input').type = 'color'检测是否支持 - 不支持时，回退为带正则校验的
input type="text"，并绑定blur和change事件做即时反馈 - 别依赖样式 hack，原生控件的 UI 权限在系统手里，强行干预只会让问题更隐蔽
最易被忽略的一点：校验只解决格式问题，不解决视觉一致性。比如 #FF6B35 在 OLED 屏上看起来比 LCD 更艳，但你的正则无法告诉用户这点——它只管字符串对不对，不管人眼接不接受。
