社区测量工具修正小数解析：10.02GB 为何会被写成 8,00GB
club-3090 新合并修复显示，西班牙语数字区域设置配合 mawk 可截掉小数。修正的是报告解析与打印，不是引擎突然少占了内存；其他语言环境的日志也要检查。
同一份启动日志，数字解析错误就能把内存规模写错。本次窗口内，club-3090 合并 PR #1930，统一脚本的数字区域设置。PR 于 11 月 3 日 22:08 UTC 合并，给出了真实 es_ES.UTF-8 环境下的复现与回归检查。这是一条测量工具修复，不是新的硬件速度测试。
-
错误如何发生。原文三张卡的 host-backed 专家数据分别为 1.65、4.56、3.81GB，合计 10.02GB。作者发现，在使用小数逗号的区域设置下，mawk 将这些带点字符串按整数部分解析，得到 1、4、3，再打印成“8,00 GB”。原文还展示了 mem_total_gib=188,5。单位看似完整、数值也不离谱，但报告已经与启动日志不一致。
-
修复改了什么。提交在执行数值工作的脚本中强制 LC_NUMERIC=C，并处理优先级更高的 LC_ALL：先把原值迁移到其他区域类别，再取消 LC_ALL，避免它继续覆盖数字设置。只改一处启动器不够，因为报告工具会把自己的输出重新读回，任何中间环节留下逗号都可能污染后续解释。
-
如何判断影响。上游自报新增检查覆盖 LANG、LC_NUMERIC、LC_ALL 三种入口；在具备真实西班牙语 locale 与 mawk 的环境验证和为 10.02GB，相关测试集合为 35/35。作者同时说明，更大范围测试提前停止，不能写成全套全部通过。这些是维护者的修复与测试自报，不是 AraoAI 独立执行的结果。
使用者先核对原始日志与报告的对应字段，再检查 locale 和 awk 实现。不要看到数字变化就宣布内存优化，也不要将主机侧专家配置量当作实测进程峰值。此次案例说明，证据链不仅需要保留日志，还要保留解析条件；一个看起来合理的数字，仍可能是工具制造的偏差。