不能用:hover直接修改grid-template-columns中的fr值实现平滑变化，因为fr是离散值，w3c规定不可插值、不可过渡，浏览器不支持对其做css过渡动画。
不能直接用 :hover 修改 grid-template-columns 中的 fr 值来实现平滑列宽变化——浏览器不支持对该属性做过渡动画，写了 transition: grid-template-columns 0.3s 也完全无效。
为什么 grid-template-columns + :hover 不生效
fr 单位属于离散值（discrete），W3C 明确规定它不可插值、不可过渡。浏览器在布局计算阶段一次性解析 grid-template-columns，之后不会因 :hover 重跑整个网格轨道分配逻辑。常见现象包括：transition 声明存在但无任何动画、悬停后列宽突变、甚至触发意外重排导致内容跳动。
更关键的是：Grid 的列宽由容器定义，不是由子项状态驱动。哪怕你只 hover 某个 grid-item，也无法靠纯 CSS 让它“拉伸自己所在列”并“压缩邻居列”——这本质是跨单元格的响应式再分配，CSS 选择器能力达不到。
替代方案：用 transform: scaleX() 模拟列宽变化
如果目标是视觉上“让某一列看起来变宽”，且不希望影响其他列位置或触发重排，transform: scaleX() 是最轻量、兼容性最好、也最容易控制的方式。
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
- 给目标列内的内容容器（比如
<div class="col-main">）加 <code>transform-origin: left center，确保缩放以左边缘为基点 - 配合
transition: transform 0.25s ease-out -
:hover时设transform: scaleX(1.15)，别超过1.2，否则右侧内容易被父容器overflow: hidden裁剪 - 必须显式设置
position: relative和z-index: 2，否则放大后可能被相邻列盖住
示例：
`.col-main {
position: relative;
z-index: 1;
transition: transform 0.25s ease-out;
}
.col-main:hover {
transform: scaleX(1.15);
transform-origin: left center;
z-index: 2;
}`
真要改列轨道？必须用 JavaScript 动态写 style.gridTemplateColumns
当交互逻辑明确要求“点击/悬停后，某列从 1fr 变成 2fr，同时另一列从 1fr 收到 0.5fr”，就得放弃纯 CSS，改用 JS 读取当前值、计算新比例、再写回内联样式。
- 不要直接操作 class 切换预设的
grid-template-columns，那样无法响应容器尺寸变化 - 监听
mouseenter/mouseleave，而非:hover，避免 iOS Safari 等不触发伪类的问题 - 写入前先缓存原始值，
mouseleave时还原，否则 resize 后状态错乱 - 慎用
transition包裹 JS 修改——浏览器对grid-template-columns的过渡支持极差，容易卡顿或跳变
简单示意：
`const container = document.querySelector('.grid-container');
const original = container.style.gridTemplateColumns;
container.addEventListener('mouseenter', () => {
container.style.gridTemplateColumns = '2fr 1fr';
});
container.addEventListener('mouseleave', () => {
container.style.gridTemplateColumns = original;
});`
真正容易被忽略的点是：所谓“动态改变列宽”，90% 的场景其实不需要动列轨道——用 transform 模拟视觉变化更稳、更快、更可控；只有当业务逻辑强依赖列宽参与后续计算（比如图表宽度绑定、打印适配）时，才值得引入 JS 干预布局层。
