Python 金额差一分钱:从 float 输入污染到 Decimal 舍入边界
场景:计算结果没报错,核对总额却对不上 订单预览、费用计算和导出报表里,容易出现两种相似的现象:2.675 保留两位变成 2.67;两条 0.335 的明细分别显示 0.34,总计却显示 0.67。前者可能是输入已经经过二进制浮点数,后者可能是逐行舍入与汇总舍入的口径不同。只把所有变量换成 Decimal,解决不了第二
Tag
包含这个标签的文章。
场景:计算结果没报错,核对总额却对不上 订单预览、费用计算和导出报表里,容易出现两种相似的现象:2.675 保留两位变成 2.67;两条 0.335 的明细分别显示 0.34,总计却显示 0.67。前者可能是输入已经经过二进制浮点数,后者可能是逐行舍入与汇总舍入的口径不同。只把所有变量换成 Decimal,解决不了第二
订单明细增加退款展示后,报表的销售额突然变大。单独查订单金额正确,单独查退款也正确,只有合并查询对不上。此时先检查关联后的数据粒度:一张订单同时对应多条商品明细和多条退款时,两组明细会组合成多行,最后的 SUM 会把同一金额累计多次。 本文以 PostgreSQL 17 为语义基准,用一套可复现数据定位问题,再把查询改
适用场景与现象 适用于 Python 3.10 及以上的命令行程序、后台任务和自有服务。业务代码只调用一次 logger.info(),同一进程的原始输出却出现两行;或者应用工厂每执行一次,同一事件就多输出一遍。 先分清重复发生在哪一层:若进程的 stderr 只有一条,而日志平台出现两条,优先检查采集路径是否同时包含
场景:有待处理订单,补偿任务却扫不到 补偿任务从订单表里找出“尚未有成功回执”的订单。原先使用 NOT IN (SELECT order_id ...),导入一条未关联订单的回执后,任务突然返回零行,接口没有报错,查询耗时也正常。 下面是隔离复现,不代表真实生产事故。SQL 按 PostgreSQL 17 编写,使用会
适用场景 本文适用于允许用户上传 ZIP 的报表导入、主题包安装、批量图片处理和离线数据交换服务。压缩包来自外部时,风险不只是文件名中出现 ../:绝对路径、Windows 盘符、反斜杠、同名覆盖、Unix 符号链接以及极高压缩比,都可能让一次普通解压变成任意文件写入或磁盘耗尽。 目标是建立一个可验收的解压边界:先检查
适用场景 本文适用于 Python 3.11 及以上版本。业务程序需要调用数据库备份工具、硬件厂商 CLI、Windows 遗留程序或内部运维命令,但这些程序的输出编码不是 UTF-8,并且可能出现长时间无响应、非零退出、输出管道堵塞或参数注入风险。 目标不是再封装一层 subprocess.run(),而是建立一个可
Python 服务用 HTTPX 转发大文件、对象存储下载或上游 SSE 时,通常会启用流式响应,避免把整个响应体读入内存。上线后却可能出现一种很迷惑的故障:服务启动时一切正常,运行一段时间后请求开始批量报 httpx.PoolTimeout;重启进程能暂时恢复,单纯调大连接池只能延后复发。 这类问题往往不是上游连接慢
调用第三方 API 的 Go 服务通常会在内存中缓存 OAuth 访问令牌,并在令牌即将过期时刷新。单实例、低并发时,这段逻辑看起来很简单;并发升高后,几十个请求可能同时发现令牌失效,又同时访问认证端点。结果不是更快拿到新令牌,而是认证服务返回 429 Too Many Requests,业务请求批量失败,甚至出现“较
适用场景 商品详情、活动配置、首页聚合数据和权限策略等读取接口,通常会把查询结果缓存在 Redis 中。平时数据库负载很低,一旦某个热点键过期,大量并发请求却可能同时回源,几百毫秒内把连接池占满,最终形成接口超时、重试放大和数据库雪崩。 本文讨论的是单个或少量热点键失效导致的缓存击穿。如果大量键在同一时间过期,属于缓存
适用场景 支付回调、代码仓库事件、消息推送和第三方审批通知通常通过 Webhook 进入业务系统。很多服务已经实现了 HMAC 签名校验,却仍会遇到重复发货、重复记账或重复触发流水线的问题。 这类故障的关键在于:签名只能证明请求内容来自持有密钥的一方,不能证明这次请求从未被处理过。 一个合法请求被代理层、第三方平台或攻