做 CSS 渐变背景时，先标出文字会出现在哪一段，再选颜色和色标位置。只看整块背景是否“好看”，很容易漏掉标题换行、按钮变宽或手机窄屏后文字刚好压在亮色区域的问题。
先画出文字的实际占位，再调背景
可读性取决于文字和它当下背景的组合，不是渐变两个端点的平均印象。先在真实组件中放入最长文案、常用字号和最窄尺寸，才知道哪些区域需要稳定对比。
例如一个“免费试用 30 天”的按钮，桌面端可能只占背景中间一段，手机端却会撑满整行。若渐变从深色走向高亮度色，白字在宽按钮的右侧可能变得很淡。解决方法不一定是换掉整组品牌色：可以把亮色节点移到文字不会覆盖的位置，也可以在文字下增加稳定的半透明底层。
确定用途也很重要。大面积首屏背景、短按钮、状态标签和数据图表的阅读路径不同，不应共用一个“看起来差不多”的验证结果。
按内容结构选线性、径向或锥形渐变
线性渐变最容易建立可预测的阅读区，径向渐变适合把视觉重心放在一个局部，锥形渐变则更适合装饰或环形表达。如果大段文字跨过多个方向快速变化的背景，阅读风险会比单一方向更难排查。
打开 CSS 渐变生成器（工具 ID 为 css-gradient）后，可以切换 linear、radial 和 conic，修改 0 到 360 度的角度，添加色标并设置百分比位置。当前组件至少保留两个色标，还提供几组预设、实时预览和 CSS 复制功能。
工具复制的是一条 background: ...; 声明。它不会替你决定文字色、字重、字号、覆盖层、聚焦边框和响应式排版，也不会证明组件已经符合无障碍要求。因此预设适合当起点，不适合当成检测报告。
把每个色标和中间段都当作检查点
渐变会产生大量中间色，所以不能只检查首尾两个色值。先找出文字会覆盖的最亮点、最暗点和视觉变化最快的区域，然后分别与文字颜色进行对比度计算。
W3C 对 WCAG 2.2 文字对比的说明给出了 Level AA 的门槛：普通文字至少 4.5:1，大字至少 3:1，并有明确例外和“大字”定义。数值不应四舍五入到及格；细字重和特殊字体即使名义上过线，实际阅读仍可能偏弱。
一个实用顺序是先把两个端点都测一次，再在文字中心、换行末端与色标附近取样。若任意必经位置不足，优先收窄色相亮度差、移动色标、改文字色，或在文字区增加稳定底色。不要仅靠阴影把明显失败的组合“补回来”。
复制 CSS 后要回到真实组件验证
复制出来的渐变只是背景值，必须放进目标页面才能检查实际结果。至少要看默认、悬停、键盘聚焦、按下和禁用状态，再测试窄屏换行、页面缩放以及浏览器高对比设置下的信息是否仍然清楚。
例如一个主按钮在默认状态使用深色渐变和白字，悬停时若直接把整个背景提亮，可能只有悬停状态失去对比。键盘聚焦环如果也取渐变中的相似颜色，则会出现“字还看得清，但焦点位置看不出来”的另一类问题。
验证时保留渐变 CSS、文字 CSS、组件尺寸与各状态的结果。这样日后文案变长或品牌色更新时，可以重复同一套检查，而不是只对着一张旧截图猜测。
两种情况应该放弃让文字直接压在渐变上
当内容位置无法预测，或只要响应式排版变动就会跨过明暗极端时，应为文字增加稳定底层。如果背景还会被运营人员不断换色，则更适合把渐变限制在装饰边框、顶部细条或文字之外的区域。
另一种情况是渐变同时承担状态信息，例如只用红到绿表示风险变化。颜色不应是唯一线索，还要配合文字、数值、图标或形状。工具能生成颜色过渡，但不能替代信息架构和用户测试。
常见问题
只检查渐变两端的对比度够吗？
不够。色标之间的中间色也可能是最不利的背景，应在文字实际经过的位置分别取样和计算。
预览里的白字能看清，就代表页面文字合格吗？
不代表。预设卡片的字号、阴影和位置与你的页面不同，必须在真实组件中验证。
应该用 linear、radial 还是 conic？
需要稳定阅读路径时优先考虑 linear；需要局部光斑时可以考虑 radial；conic 更适合环形或装饰效果。最终选择要以内容位置和实测结果为准。
用文字阴影就能解决对比不足吗？
阴影可以改善部分边缘，但不应用它掉包明显不足的文字与背景组合。优先调整颜色、色标位置或增加稳定底层。
生成器会自动检查 WCAG 对比度吗？
不会。当前工具负责预览和生成 background CSS，没有文字颜色输入、对比度计算或合规证明功能。