HTML单位换算与格式转换不直接冲突，但DOM渲染、CSS计算和JS读取时因值被提前转为像素（如getComputedStyle返回"240px"）导致原始单位丢失；需从el.style或CSSOM解析原始值，JS中应统一用parseFloat提取数值、正则提取单位，并注意em/rem基准及CSS变量单位传递陷阱。
HTML 单位换算本身不会和格式转换冲突，但实际开发中，两者在 DOM 渲染、CSS 计算和 JS 读取环节容易互相干扰——关键在于「谁在什么时候把值转成了什么形式」。
用 getComputedStyle 读取带单位的值时，浏览器已做完换算
比如元素写的是 width: 50% 或 font-size: 1.5em，调用 getComputedStyle(el).width 返回的一定是像素值（如 "240px"），不是原始声明值。这意味着：
- 你无法直接从
getComputedStyle反推原始单位（%、em、rem都消失了） - 若后续要做「百分比转视口单位」或「rem 转 px」类格式转换，此时再处理已无意义——它已经是 px 了
- 想保留原始单位语义，得从
el.style.xxx或 CSSOM 规则里手动解析，不能依赖计算样式
JS 手动做单位换算时，parseInt 和 parseFloat 的行为差异很关键
很多开发者用 parseInt("1.5em") 得到 1，误以为是单位问题，其实是 parseInt 遇小数点就停。正确做法是：
- 统一用
parseFloat("1.5em")提取数值部分（返回1.5） - 用正则
/.+?(?=px|em|rem|%)/或String.prototype.match提取单位（注意要覆盖vh、vmin等） - 对
em/rem换算，必须明确基准：当前元素的font-size（em）或根元素font-size（rem），不能硬编码16
CSS 自定义属性（--size）传值时，单位丢失是常见陷阱
如果这样写：style="--size: 1.2;，然后在 CSS 里写 width: calc(var(--size) * 1rem);，看着没问题，但实际：
立即学习“前端免费学习笔记（深入）”；
-
--size是纯数字，没单位，calc()里乘1rem才补上单位 - 但如果 JS 读取
getComputedStyle(el).getPropertyValue('--size')，拿到的是字符串"1.2 "（带空格），parseFloat还能救，但parseInt又翻车 - 更稳妥是传带单位的值：
style="--size: 1.2rem;"，再用calc(var(--size) * 1)保持类型安全
单位换算真正出问题的地方，往往不在公式本身，而在「哪一层负责解析单位」「谁该持有原始语义」「何时触发重排重绘」——这些细节不显眼，但改一个 offsetWidth 读取时机，就可能让整个响应式布局错一帧。
