rem 作为前端开发中常用的长度单位，虽然方便灵活，但也存在一些弊端：
-
依赖根元素字体大小:
rem的值是相对于根元素（通常是<html>元素）的font-size计算的。这意味着如果用户更改了浏览器的默认字体大小，或者开发者在其他地方修改了根元素的font-size，页面布局可能会被打乱。这对于需要精确控制布局的场景，或者需要兼容各种用户自定义设置的场景来说，是一个挑战。 尤其在移动端，用户调整字体大小的情况更为常见。 -
计算复杂性: 虽然浏览器可以处理
rem的计算，但在开发过程中，开发者需要不断地进行换算，例如将px转换为rem。这增加了开发的复杂性，尤其是在需要精细调整布局的时候。可以使用一些工具或预处理器（如Sass、Less）来简化这个过程，但仍然需要一定的学习成本。 -
浏览器兼容性 (老旧浏览器): 虽然现在主流浏览器都支持
rem，但一些非常老旧的浏览器可能不支持，或者支持不完善。需要针对这些浏览器进行兼容性处理，例如使用px作为后备方案。 不过，这在现代前端开发中已经很少遇到了。 -
媒体查询中的挑战: 在媒体查询中使用
rem时，需要格外小心。如果媒体查询修改了根元素的font-size，那么所有使用rem的元素的大小都会随之改变，这可能导致布局出现意外的变化。 需要仔细规划和测试，确保在不同屏幕尺寸下布局的正确性。 -
嵌套计算的复杂性: 如果在嵌套的元素中都使用
rem，并且这些元素的父元素也使用了rem，计算会变得更加复杂。 需要仔细考虑层级关系和计算方式，避免出现意外的结果。 -
可访问性问题: 对于使用屏幕阅读器的用户来说，如果页面布局依赖于
rem并且用户更改了默认字体大小，可能会导致页面难以阅读或导航。 需要确保在用户调整字体大小后，页面仍然保持良好的可访问性。
总而言之，rem 虽然方便，但也需要谨慎使用。开发者需要权衡其优势和劣势，根据项目的具体需求选择合适的长度单位。 在某些场景下，结合使用 rem 和 px 或者其他单位，例如em，vw, vh 等，可能是一个更好的解决方案。