在我的HTML中，我有一个固定宽度的
标签（称之为面板），其中包含一些文本；该文本在附带的CSS中设置为font-size: 25px; line-height: 25px;。恰好这段文本最终成为36行。
考虑到所有边距、填充和边框都是零，您期望面板的高度为36 * 25px = 900px，并且在使用DOM的getBoundingClientRect()方法时，在Firefox中实际上也是这样。
然而，在Google Chrome中，我得到了不同的数字。看起来面板只有892.7999877929688像素高，而行高为24.799999660915798像素。这两个数字的除法仍然为36。在CSS中设置的标称像素与getBoundingClientRect()报告的真实像素之间似乎存在缩放比例；对于我的情况，这是1.0080645299120465名义每真实像素。
更多证据来自在nwjs应用程序中运行的Chromium，在那里我最初观察到了差异。在我的测试期间，它显示出一个与Chrome中不同的比率。现在，在我的测试过程中，由于某些原因，Chromium报告的像素突然跳至Firefox报告的整数值；我不确定我做了什么才能让这种情况发生。
可以预期，小型缩放比例与页面缩放有某种联系；毕竟，在非常小的大小下，Chrome和Chromium会重新排列文本（有时做得不正确）。而且，改变Chrome中的缩放级别会导致不同的比例，并使Chrome最大化缩放将比例设为1。但是，我的Chromium应用程序没有放大到最大，并且在测试中具有整数像素比率，但在实际应用中具有小数值。
就目前所知，我所能做的就是设置一个已知大小的盒子并测量它来获取比率，以便使用JavaScript进行准确、一致的盒子大小测量。
考虑到所有边距、填充和边框都是零，您期望面板的高度为36 * 25px = 900px，并且在使用DOM的getBoundingClientRect()方法时，在Firefox中实际上也是这样。
然而，在Google Chrome中，我得到了不同的数字。看起来面板只有892.7999877929688像素高，而行高为24.799999660915798像素。这两个数字的除法仍然为36。在CSS中设置的标称像素与getBoundingClientRect()报告的真实像素之间似乎存在缩放比例；对于我的情况，这是1.0080645299120465名义每真实像素。
更多证据来自在nwjs应用程序中运行的Chromium，在那里我最初观察到了差异。在我的测试期间，它显示出一个与Chrome中不同的比率。现在，在我的测试过程中，由于某些原因，Chromium报告的像素突然跳至Firefox报告的整数值；我不确定我做了什么才能让这种情况发生。
可以预期，小型缩放比例与页面缩放有某种联系；毕竟，在非常小的大小下，Chrome和Chromium会重新排列文本（有时做得不正确）。而且，改变Chrome中的缩放级别会导致不同的比例，并使Chrome最大化缩放将比例设为1。但是，我的Chromium应用程序没有放大到最大，并且在测试中具有整数像素比率，但在实际应用中具有小数值。
就目前所知，我所能做的就是设置一个已知大小的盒子并测量它来获取比率，以便使用JavaScript进行准确、一致的盒子大小测量。
我仍然在想观察到的行为的来源是什么。是否有任何报告？这是渲染器的故意行为还是 emergent 行为？开发者曾经讨论过这个问题吗？是否有 API 可以获取比例？
我在 https://gist.github.com/loveencounterflow/d8c20b9021d2ab3f573a 上放置了一些代码，以简化测试。
jQuery(...).height()这样的方法总是返回整数像素。很明显，在允许盒子宽度为 100 像素的三分之一的环境中进行适当的布局，必须在某个地方有大整数（如 TeX 所做的那样）或分数像素。使用 ClearType 等技术，甚至可以近似地呈现分数像素。 - flow