原生<input type="color">基础用法是直接弹出系统级调色面板，值恒为7位小写十六进制（如"#ff0000"），不支持透明度、命名色或rgb/hsl格式；必须显式设合法hex值（如value="#3a86ff"），否则静默回退至"#000000"；监听应优先用oninput实现实时响应，onchange仅在确认后触发；样式定制极受限，仅宽高和光标可调，深度定制需隐藏原生控件并用canvas或第三方库替代。
color 类型 input 的基础用法和默认行为
原生 <input type="color"> 就是浏览器内置取色器，不需要额外 JS 或库就能弹出系统级调色面板。它本质是一个带颜色预览的文本框，值始终是 7 位十六进制格式（如 "#ff0000"），且不支持透明度（alpha）——哪怕用户在 macOS 或 Chrome 的拾色器里拖动不透明度滑块，value 也只会返回不含 alpha 的 #rrggbb。
常见误操作：给它设 value 为 "rgb(255,0,0)" 或 "red"，浏览器会静默忽略并重置为默认值（通常是 #000000）。必须用合法的 4 位或 7 位 hex 格式。
-
<input type="color" value="#3a86ff">✅ 有效 -
<input type="color" value="blue">❌ 无效，输入框显示黑色 -
<input type="color" value="#f00">✅ 等价于#ff0000，会被标准化为 7 位
监听颜色变化：oninput vs onchange
oninput 在每次颜色选择后立即触发（包括拖拽滑块过程中），而 onchange 只在用户确认关闭拾色器时触发一次。实际开发中几乎都该用 oninput，否则用户拖动取色滑块时无法实时响应。
注意：Chrome 和 Edge 中，点击色块后直接点“取消”，oninput 仍会触发一次（值为上次选中的颜色）；Firefox 则更严格，取消时不触发。别依赖“取消=值不变”这个逻辑。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
<input type="color" id="picker" oninput="console.log(this.value)">
样式定制限制与绕过方案
浏览器对 <input type="color"> 的样式控制极弱：background、border 等常规属性大多被忽略，唯一可靠的是 width、height 和 cursor。想改按钮颜色？不行。想隐藏默认色块只留文字？也不行。
如果需要深度定制（比如圆角色块、带 alpha 滑块、历史颜色栏），必须放弃原生控件，用 <canvas> 或第三方库（如 react-color 或 vanilla-picker），然后把最终选中的 hex 值同步到一个隐藏的 <input type="hidden"> 中供表单提交。
- 原生控件适合快速原型或后台管理页等对 UI 要求不高的场景
- 产品级应用中，用户对色彩精度和交互反馈要求高，原生控件往往不够用
移动端兼容性与实际表现差异
Android Chrome 和 iOS Safari 都支持 type="color"，但行为不同：Android 弹出 Material Design 风格色盘，iOS 则调用系统原生色彩选择器（带色相环+明度滑块）。关键问题是——iOS 上点击输入框后，键盘会意外弹出（即使 focus 后立刻 blur 也无法完全阻止），这是 WebKit 的已知 bug。
规避方式：给 input 加 readonly 属性（不影响点击触发拾色器），或监听 focus 后立即 blur()，但后者在部分 iOS 版本中仍有残留键盘。
- 测试时务必真机验证，模拟器常无法复现键盘问题
- 若项目必须支持 iOS 且不允许键盘出现，只能换自定义实现
color 输入框省事，但它的“省事”只存在于最简场景；一旦涉及 alpha、历史记录、主题适配或 iOS 键盘干扰，就得立刻切换技术路径。 
