PHP ini_parse_quantity 怎么解析内存大小配置值

我第一次认真处理 PHP 的容量配置，不是在写 php.ini，而是在一个配置汇总页里比较 memory_limit、上传限制和应用自己的缓存上限。问题很快暴露出来：ini_get() 读到的是 128M 这样的字符串，直接转成整数只会得到前面的 128，手写单位换算又容易在大小写、进制和错误输入上各写一套。

PHP 8.2 起可以直接调用 ini_parse_quantity()。它接收 ini 简写字符串，按 PHP 自己的规则解释，并返回字节数整数。像 128M 会得到 134217728，512K 会得到 524288。PHP 官方手册地址：https://www.php.net/manual/en/function.ini-parse-quantity.php

手写解析在配置变多后很快失控

单个项目只有一个 128M 时，用 rtrim() 再乘 1024 看起来够用。我后来把同一段逻辑放到命令行检查、健康页和部署前校验里，才发现真正的成本不是那几行乘法，而是每份代码对边界的理解不一样：有人只认大写 M，有人把 1G 当十进制十亿，还有人遇到错误单位时直接返回 0。

当配置来自 php.ini、环境模板和应用参数多个入口时，继续复制手写函数只会扩大分歧。更稳妥的边界是：先保留原始字符串，再统一交给 PHP 的解析函数，最后由业务层判断这个配置值是否合理。

把配置字符串统一转换成字节

最小用法只有一行，但实际代码最好同时保留原值。这样日志能显示管理员写下的配置，也能显示程序用于比较的字节数。

如果当前配置是 128M，$limitBytes 就是 134217728。这时它可以直接和 memory_get_usage(true)、上传文件大小或应用阈值比较，不必再猜单位。

我更愿意把这个转换放在配置装载边界，而不是散落在每个业务函数里。这样后面的服务只接收 int 字节值，原始简写只用于展示和审计。规模变大后，收益主要来自“只有一个解释入口”，而不只是少写几行代码。

K、M、G 和不同进制到底怎么算

官方手册列出的乘数是二进制容量单位：K/k 为 1024，M/m 为 1048576，G/g 为 1073741824。数字部分不仅可以是十进制，也支持带前缀的十六进制、八进制和二进制。

 %d bytes\n", $sample, ini_parse_quantity($sample));
}

这里最容易出现的误判，是把 1M 当成 1000000 字节。配置页如果要显示 MiB，可以在转换后除以 1024 * 1024；如果产品界面坚持使用十进制 MB，则应明确标注，不能把两套单位混在同一列。

无效输入和特殊值要分层处理

ini_parse_quantity() 对无法解析的输入或未知乘数会发出 E_WARNING。但它为了兼容既有 ini 行为，仍可能返回一个解释后的整数。例如官方示例中，Foobar 发出警告后返回 0，10F 发出未知乘数警告后返回 10。

这意味着生产代码不能写成“返回 0 就失败，非 0 就成功”。更可靠的办法是，在你确实要接收外部配置字符串时，把警告转换成异常，再由配置层决定回退、拒绝启动还是采用默认值。

这段包装器的代价是它会临时接管当前作用域的 E_WARNING。因此要保持调用范围短，并在 finally 中恢复处理器。不要在整个请求生命周期里长期修改全局错误处理策略。

memory_limit 的 -1 不能只当普通字节数

PHP 官方对 memory_limit 的定义中，-1 表示不设置内存上限。ini_parse_quantity('-1') 得到的整数可以保留，但如果随后拿它和当前内存使用量直接比较，几乎所有正数都会“大于 -1”，业务判断就会反过来。

我会先处理配置项自己的语义，再做普通数值比较：

这个分层很重要：ini_parse_quantity() 负责“这段 ini 简写对应哪个整数”，它并不替你判断每个配置项的业务含义。类似地，某些配置是否允许 0、是否有最小值、是否受 32 位整数范围影响，都应由调用方结合具体指令判断。

兼容旧版本时别复制一份半成品解析器

PHP 8.1 及更早版本没有 ini_parse_quantity()。如果代码库要同时支持旧环境，可以先用 function_exists() 明确分支。我的取舍是：核心服务直接把最低版本提升到 8.2；无法升级的维护分支则使用项目内经过测试的兼容函数，并把它限制在一个文件中。

不建议为了“兼容”临时写一个只识别最后一个字符的三行函数，然后让它扩散到多个服务。它通常忽略进制、无效前缀、警告语义和整数范围，表面上能解析 128M，却不能保证与 PHP 真正解释 ini 的方式一致。

上线前用一组边界值做检查

即使不运行复杂测试，也应至少覆盖无单位、小写单位、三种常用单位、不同进制、无效数字和无效乘数。判断标准不是“脚本没报错”，而是合法值转换正确、非法值进入预期的错误分支、特殊配置值没有被普通比较逻辑误用。

• 1024：确认无单位时按字节解释。
• 512k 与 512K：确认单位大小写都支持。
• 1M、1G：确认采用 1024 进制乘数。
• 0xFFk、0b1010k：确认项目没有额外禁止这些官方支持的进制。
• Foobar、10F：确认 E_WARNING 被记录、转换或明确处理。
• -1：确认只在对应配置项允许时解释为特殊语义。

如果这些值来自用户表单，还要在进入 ini_parse_quantity() 前限制长度和允许格式，避免把 PHP 的兼容返回行为误当成表单校验。解析函数解决的是 ini 语法，不是完整的业务输入验证。

相关问题

ini_get() 为什么不直接返回字节整数？

ini_get() 返回配置项的字符串值，保留了 128M 这样的 ini 表达。需要字节整数时，再显式调用 ini_parse_quantity()，可以让读取与解释两个责任更清楚。

小写 k、m、g 能解析吗？

可以。官方手册明确支持 k/K、m/M、g/G，乘数分别为 1024、1048576 和 1073741824。

无效输入为什么有警告还返回整数？

这是为 ini 既有解释行为保留的兼容方式。调用方必须同时处理 E_WARNING，不能把返回整数单独当成“输入有效”的证明。

可以用它解析 1T 吗？

官方列出的乘数只有 K、M、G。T 不是受支持的乘数，会触发无效乘数警告。需要更大单位时，应在业务层定义独立且经过范围检查的格式。

总结：ini_parse_quantity() 最有价值的地方，是让应用与 PHP 对 ini 容量简写使用同一套解释规则。PHP 8.2 以上直接用它把配置字符串转换为字节；同时保留原值、处理 E_WARNING、单独解释 memory_limit=-1，并在旧版本上明确失败或进入受测兼容层，配置越多时越能减少各服务之间的换算分歧。