硬过渡条纹的关键是相邻色标值完全相等，如#000 25%,#fff 25%，浏览器不插值而直接拼接；若用px单位需防subpixel渲染发虚，推荐统一用百分比定义色标并配合background-size控制密度。
repeating-linear-gradient 怎么写才出条纹
硬过渡条纹的关键不是“重复”，而是让颜色停止点紧挨着——两个相邻色标值必须完全相等，不能留空隙也不能重叠。浏览器会把相同位置的两种颜色直接拼接，不插值，就形成清晰分界。
常见错误是写成 repeating-linear-gradient(90deg, #000 0%, #000 25%, #fff 25%, #fff 50%)，看着对，但其实 #000 25% 和 #fff 25% 在同一位置，属于合法硬切；而如果写成 #000 24%, #fff 26%，中间 2% 就会被平滑过渡，条纹变虚。
- 必须用百分比（或固定长度）显式写出每个色标位置，不能省略第二个值（如
#000单写会默认为#000 0%，易引发意外过渡） - 重复单元长度 = 最后一个色标值（如
50%），整个渐变会按此长度无限平铺 - 方向角影响条纹走向：
0deg是从下往上，90deg是从左往右，别和 background-size 直觉搞反
为什么 background-size 配合 repeating-linear-gradient 容易错
很多人以为设了 background-size: 20px 20px 就能控制条纹宽高，其实它只缩放「整个重复单元」，不是单个色带。如果渐变定义里单元是 50%，那 background-size: 20px 20px 就等于把 50% 映射到 20px——此时每个色带实际宽度取决于你在色标里怎么分的。
典型翻车场景：想做 2px 黑 + 2px 白横纹，却写成 repeating-linear-gradient(0deg, #000 0%, #000 2px, #fff 2px, #fff 4px) 再配 background-size: 4px 100%。问题在于，这种写法在高 DPR 屏幕或缩放时，2px 可能被渲染为非整像素，边缘发虚；而用百分比才能随容器自适应。
立即学习“前端免费学习笔记（深入）”；
- 推荐统一用百分比定义色标，再用
background-size控制整体密度（例如4px 4px表示每 4px 重复一次单元） - 若坚持用 px 单位，务必配合
background-repeat: repeat（默认就是），且避免和background-position混用导致偏移错位 - Firefox 对 px 色标在 subpixel 渲染上更敏感，Chrome 相对宽容——测试时别只看一个浏览器
兼容性与性能要注意什么
repeating-linear-gradient 在所有现代浏览器都支持，包括 IE10+，但 IE10–11 不支持颜色关键词后的空格（比如 red 0% 可以，red 0% 多个空格会解析失败），也拒绝 HSLA 中带空格的写法（hsla(0,0%,0%,0.5) 0% 安全，hsla(0, 0%, 0%, 0.5) 0% 在 IE 下挂）。
性能上，它比拼贴多张小图或 SVG 更轻量，但比纯单色 background-color 多一丢丢计算——不过只要没动画、没大量元素同时用，基本感知不到。
- 避免在
:hover或@keyframes里动态改这个渐变值，重绘开销明显上升 - 不要用它模拟复杂纹理（比如斜线+网点叠加），CSS 渐变层级能力弱，容易糊或错位
- 需要响应式条纹时，别用媒体查询反复重写整个
background-image，改用calc()或 CSS 自定义属性动态算色标位置更干净
调试时怎么看色标是否真硬切
最直接的办法：把两个相邻色标改成对比极强的颜色（比如黑→品红），然后放大 400% 看边缘。如果有任何灰阶过渡带，说明它们位置没对齐，或者单位混用了（% 和 px 混写）。
另一个信号是 DevTools 里审查元素，点开 background-image 值，如果看到类似 repeating-linear-gradient(90deg, #000 0%, #000 10%, #fff 10%, #fff 20%) 这种“首尾相接”的结构，基本没问题；但如果出现 #000 10%, #fff 11% 或者漏写了某个位置（如 #000, #fff 10%），那就注定软边。
- Chrome DevTools 的 color picker 无法取渐变中间色，别指望它验证硬切效果
- 用
background-clip: text把条纹套在文字上，是检验精度的好方法——锯齿或模糊立刻暴露 - 移动端 Safari 对小尺寸（
