日元没有"分",退款要带流水号:支付代码里两条要命的规矩
0.1 + 0.2 ≠ 0.3,收钱的代码不能有浮点;但「分 = ×100」也是误区——日元小数 0 位、第纳尔 3 位。退款必须带稳定流水号做幂等,超时先查单再重试。任何语言都用得上的两条支付军规。
实事求是的技术与产品记录:每一个数字、每一笔提交,都可以在 git 仓库里复核。
0.1 + 0.2 ≠ 0.3,收钱的代码不能有浮点;但「分 = ×100」也是误区——日元小数 0 位、第纳尔 3 位。退款必须带稳定流水号做幂等,超时先查单再重试。任何语言都用得上的两条支付军规。
伪造一条「支付成功」回调只需要一条 curl。验签就是验防伪章:RSA2/平台公钥/HMAC 三种章怎么验,±300 秒防重放、常量时间比较、核对 app_id——以及最重要的误区:验签通过 ≠ 可以发货。
官方 SDK 没有 Erlang 版?纯 Erlang 支付网关库 erlang_pay:一套 API 接支付宝 App、微信支付 v3、Stripe,下单/退款/回调验签/对账全生命周期。10 个源文件 2741 行,运行时仅依赖 OTP + jsone,213 个测试用例真签名验证。
推送像快递员送货上门,同步像自己去快递柜取件——IMBoy 消息不丢的真正保证在同步层而非推送层。讲清 IM 的推拉两层设计与 ACK 的真实定位。
6 个源文件、约 1000 行代码,如何同时支持 PostgreSQL、MySQL、SQLite?behaviour 接口分层、两阶段 dirty 标记、三种锁实现对比——从源码拆解一个简洁的 Erlang 设计范本。
Ruby 有 ActiveRecord Migrations,Go 有 golang-migrate,那 Erlang 呢?像素级对标 golang-migrate v4 的设计:up/down 回滚、dirty 状态保护、分布式锁,PostgreSQL/MySQL/SQLite 三库支持,零运行时依赖。