flex-grow小数本身合法无偏差，问题源于flex-basis与内容宽度混算导致剩余空间过小，叠加浏览器subpixel舍入误差被放大。
flex-grow 小数本身不导致偏差，真正出问题的是 flex-basis 和内容尺寸混算
flex-grow 接受小数（如 flex-grow: 0.5）完全合法，CSS 规范明确支持。偏差从来不是因为写了 0.5，而是浏览器在计算“剩余空间”时，把小数系数和非零 flex-basis、内容宽度、四舍五入误差叠在一起算，结果就飘了。
典型场景：三个子项分别设 flex-grow: 1、flex-grow: 0.5、flex-grow: 0.5，本意是 2:1:1，但最终宽度比接近 1.8:1:1 —— 不是因为 0.5 算错，而是第一个项的内容宽了 3px，它多占的这 3px 不参与 grow 分配，但拉高了所有项的基线。
为什么 flex-basis: auto + 小数 grow 会放大误差
当 flex-basis 是默认的 auto（即按内容宽度定起点），小数 grow 的比例作用对象就变成了「容器宽 − 所有内容宽度之和」这个残差值。这个残差往往很小，甚至为负（内容已撑满），此时 tiny 的小数系数乘上 tiny 的剩余空间，任何像素级舍入（比如 Chrome 对 subpixel 宽度四舍五入到最近整数）都会被显著放大。
-
flex: 1 1 auto→ 起点是内容宽，grow 在残差上分，小数系数易被淹没 -
flex: 1 1 0→ 起点归零，剩余空间 = 容器宽，小数系数才有意义 - 含中文/图标/图片的子项，
min-content宽度难预测，进一步干扰残差计算
移动端和 Safari 下小数 grow 更容易翻车
iOS Safari（尤其 ≤16.4）和部分安卓 WebView 对 subpixel 布局处理保守，遇到 flex-grow: 0.6 这类值时，可能直接截断为 0 或向上取整为 1，尤其当父容器高度/宽度未用 px 显式固定时。微信小程序基础库 2.25+ 虽支持小数，但若父容器只写 height: 100% 而没设祖先高度链，flex-grow 整体失效，小数自然无从谈起。
- 必须确保父容器主轴尺寸可计算：
width: 375px或min-width: 100vw，避免width: auto - Safari 中慎用
flex-grow: 0.33这类值，改用flex: 1 1 0+ 三等分容器更稳 - 调试时看开发者工具的
Computed面板里flex-grow解析值是否真为0.33，还是显示0或inherit
想用小数 grow 又要稳定，必须切断内容干扰
小数 grow 的唯一可靠场景，是所有子项起点一致、剩余空间充足、且浏览器能精确渲染 subpixel。这要求你主动清掉所有隐性变量：
- 统一写
flex: 0.5 1 0，而不是分开写flex-grow: 0.5（避免flex-basis残留默认值） - 给子元素加
min-width: 0，尤其内部有图片、input、textarea等替换元素时 - 禁用可能撑宽的属性：
white-space: nowrap、font-size差异、padding不一致 - 用
box-sizing: border-box统一盒模型，防止border/padding溢出干扰总宽计算
真正麻烦的从来不是小数本身，而是你忘了 flex-grow 从不碰内容宽度 —— 它只在“清空起点”之后，才老老实实按系数切那块明确的剩余空间。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
