caret-color在Safari 11.0及更早、所有IE、Android 4.4 WebView、Electron旧Chromium（如9x）中完全不生效；Safari 15.4前不支持，iOS 15.3及更早设备亦无效；部分厂商系统（如Samsung One UI）会强制覆盖该值。
caret-color 在哪些浏览器里根本不会生效
不是所有浏览器都认 cacet-color。Safari 11.0 及更早、所有 IE、Android 4.4 WebView、Electron 基于旧 Chromium（如 9x）的应用，会静默忽略该属性——DevTools 里连 warning 都没有，Computed 标签页也压根不显示它。
更现实的限制是：Safari 15.4 才开始支持，而 iOS 15.3 及更早设备仍占一定存量；部分 Samsung One UI 等厂商定制系统会强制覆盖该值，哪怕写了也白写。
- 检查方式：打开 DevTools → Elements → 选中
input→ 切到 Computed 标签页，搜索cacet-color，看是否出现在“有效样式”列表里 - 别依赖
@supports (caret-color: auto)做检测——Safari 15.4 前版本不支持这个@supports查询，会导致误判 - 移动端真机测试比模拟器可靠，尤其软键盘弹出后，iOS Safari 可能重置光标为系统色
为什么写了 caret-color 却没变色，但浏览器明明支持
常见失效原因和浏览器是否支持无关，而是样式没落到真实可编辑元素上。
-
input[type="number"]、input[type="date"]、input[type="time"]在 WebKit/Chromium 中被硬编码禁用cacet-color，加!important也没用 - 框架 scoped style 或 shadow DOM 封装了
input，导致你写的规则作用在父容器而非原生输入节点 - 父级设了
color: transparent，而cacet-color不继承，子元素又没显式声明，结果光标透明不可见 - 某些 reset.css（如 normalize.css）全局设了
cacet-color: auto，把你自定义的值覆盖了
伪元素模拟光标为什么基本不可行
用 ::after + position: absolute 模拟光标，看似简单，实际踩坑密集：
- 无法精准跟随光标位置：
getSelection().getRangeAt(0)在 iOS Safari 上受限，range.getBoundingClientRect()在软键盘弹出时返回异常坐标 - 焦点状态混乱：原生光标仍闪烁，伪光标只是叠在上面，用户看到两个光标或闪烁不同步
- 破坏可访问性：屏幕阅读器、Switch Control、VoiceOver 等完全无法识别伪光标，且可能因
pointer-events: none或visibility: hidden导致焦点管理失效 - contenteditable 元素中，selection API 在只读态、富文本嵌套、跨节点编辑等场景下行为不稳定
真正能落地的替代方案只有这几种
别试图“强行统一”，优先接受平台差异；必须干预时，按优先级选择：
- 对
type="number"：改用type="text" inputmode="numeric"+ JS 校验，既绕过限制，又保留光标可控性 - 对老 iOS：放弃光标颜色定制，转而强化
outline或border-bottom的焦点反馈，例如outline: 2px solid #007bff; outline-offset: 2px; - 对
contenteditable且需隐藏光标：仅在 Safari 15.4+ / Chrome 105+ 等明确支持的环境用cacet-color: transparent，并配套[contenteditable]:focus { outline: none; }和::selection { background: transparent; } - 深色模式下务必配
@media (prefers-color-scheme: dark)单独设置，避免cacet-color: white在浅灰背景上因对比度不足被系统降级
最常被忽略的一点：macOS 和 iOS Safari 会基于可读性自动调整光标色——哪怕你写了 cacet-color: #ffffff，也可能变成深灰，这不是 bug，是系统级干预，无法绕过。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
