显示两位小数，不代表计算过程准确
模型提取金额后，直接用JavaScript小数相加可能出现0.30000000000000004。toFixed改变显示形式，不能自动修正输入单位、精度和舍入规则。先明确业务允许的金额格式，再决定如何计算。
本篇只讨论非负、最多两位小数的十进制元字符串。它不是会计、税务或汇率算法；有退款、折扣分摊和多币种时，需要另定业务规则。
给原始值保留单位与文本
虚构两条材料分别为0.10元、0.20元。提取时保留原始字符串和元单位，不先交给Number解析。人工期望是10分加20分，合计30分。
文末函数拆开整数与小数部分，小数不足两位时右补零，用BigInt形成分，最后在本例明确的范围内转为Number。它不是将浮点数乘100后再猜应当怎样取整。
哪些输入应该拒绝
示例接受0、12.3、12.30；拒绝1.005、负数、千分位逗号、科学计数法、前后空白及数字类型。十位整数上限是本站教学约束，不是任何金融服务的官方限制。
1.005如何处理必须先问业务，而不是在提取时默默舍入成1.01。材料只有“元”也不能猜是人民币以外哪种币种；多币种记录不可直接相加。
运行同一组虚构金额
保存为decimal-yuan-to-fen.mjs，用Node.js 24 LTS运行node decimal-yuan-to-fen.mjs --demo。float显示原生小数相加结果，fen应为30，zero为0。
最大允许金额9999999999.99元转为999999999999分，仍在安全整数范围；测试验证了该边界。代码只展示两项小额求和，多条累计还必须验证总和未超过安全范围，不能从单条安全推断总额安全。
要求Claude给出验收清单
给出字段含义、单位、允许格式和拒绝策略，让它先列正常与异常样例，再写函数。验收至少包括零、一位小数、两位小数、三位小数和金额相同的重复记录。
对重复记录的处理取决于记录ID与业务事实，不能因为金额相同就去重。原始金额、转换后的分和来源行号应能对应，方便识别提取错误还是算法错误。
已运行范围
本地测试覆盖精确转换、格式拒绝和最大单值，没有调用模型、支付服务或真实账单。RFC 8259用于理解JSON数字的互操作边界，本站的元转分函数不是RFC规定的金额格式。
上线前用授权副本核对合计与明细，并保留异常记录给人工处理。不要为了让总数一致，删除未知小数位或覆盖原始材料。
参考资料与核验范围
资料核对日期：2026年10月21日。以下为官方原始资料；产品入口和可用范围仍以当前账户为准。
1. [官方资料1](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)
2. [官方资料2](https://www.rfc-editor.org/rfc/rfc8259)