Python构建即期利率曲线：Bootstrap剥离与XIRR任务收益率

做固收核算、理财台账或者投研支持的朋友大概率都被同一类需求追过手上有一堆券的票息、付息频率、到期日、净价全价对方要你在第二天开盘前把即期利率曲线拉出来或者更朴素一点一笔投资分几次投进去、中间又分几次回款要算一个真实的年化收益率。前一件事是即期利率spot rate的剥离后一件事我习惯叫它任务收益率计算——不管是产品户、专户还是个人台账口径是同一套。用Python来处理这两件事其实都不复杂难的全在细节里计息频率怎么对齐、天数规则用哪一种、Bootstrap的剥离顺序会不会错位、求解器为什么不收敛、浮点误差怎么把一条本来很平滑的曲线抖成锯齿。这篇就把我平时用的整套东西摊开讲从概念辨析到代码实现、从参数取值到踩坑排查全部落到可以直接复现的程度。不需要你有很深的量化背景会写基础Python、知道什么是现金流就能跟着走完。有经验的朋友可以直接跳到第3、第4节看实现和口径对比。1. 先想清楚要算的是哪一种利率1.1 到期收益率、即期利率、远期利率三个概念别搅在一起刚接触这块最容易犯的错是把债券的收益率当成一个东西。实际上至少有三种口径混用就会算出一堆看着合理、实际对不上的数。到期收益率YTM是让债券全部现金流现值等于当前价格的单一折现率本质是一个内部收益率。它隐含了两个假设持有到期且所有票息都能按这个YTM再投资。现实里第二个假设基本不成立所以YTM只是一个报价惯例不是真实回报。即期利率spot rate是零息债的到期收益率也就是今天把钱放进去、中间一分钱不拿、到期一次性还本付息所对应的年化利率。它才是真正干净的折现率第n年的现金流就该用第n年的即期利率去折。远期利率forward rate是从即期曲线里反推出来的、市场隐含的未来某段期间的利率。三者关系可以写成一个很短的式子$$(1z_n)^n (1z_{n-1})^{n-1} \times (1f_{n-1,n})$$打个生活化的比方YTM像把一堆不同甜度的水果打成果汁之后测出来的平均糖度喝起来是那个味但你不知道每颗水果到底多甜即期利率是挨个给每颗水果单独测糖度远期利率则是根据今天测的糖度去推测下个月再进一批货大概什么甜度。做估值、做曲线、做套利测算用的都是即期利率和远期利率只有做报价对比、做持有到期测算的时候YTM才上场。搞清楚这个后面代码里为什么要有两套定价函数就顺理成章了。1.2 为什么这类计算值得从电子表格搬到代码里我见过太多用表格维护的利率曲线问题不在算错而在不可复现。改一个价格整条曲线的手工剥离顺序都要跟着调整加一只新券得重新排一遍公式换个人接手看见一列嵌套七八层的单元格引用直接懵。用代码做这件事收益主要有三点。第一是可复现同一份输入跑出来永远是同一个结果出问题能定位到具体某一行。第二是可批量几百只券的YTM、上千条现金流的XIRR循环一次就完事不用一个一个拖公式。第三是可测试你写完一个定价函数可以立刻用给定即期曲线反算价格再用价格反解YTM看能不能回到原值这种方式自检这在表格里几乎做不到。代价也有前期要把数据结构设计好后面改起来才不痛。所以第2节我会花不少篇幅讲日期和现金流这两块地基地基歪了上面全是白算。1.3 技术栈与代码组织依赖就三个numpy做向量化、scipy做求根和拟合、datetime处理日期。pandas可选批量处理时用来装结果比较顺手。我一般会拆成四个模块文件不大但职责清晰daycount.py天数规则、年化因子换算bond.py现金流构造、定价、YTM求解curve.pyBootstrap剥离、插值、远期利率returns.py任务收益率、XIRR、组合汇总这么拆的好处是天数规则这种东西一旦写错会影响所有模块单独放一个文件方便你写单元测试反复验证。我吃过这个亏——早期把天数计算内联在各个函数里后来发现30/360的月末规则写错了改了六七个地方还漏了一个。2. 地基部分日期、天数规则与现金流2.1 天数规则不是小事它能让结果差出几十个基点年化因子year fraction是两个日期之间的年数不同市场惯例算法不同。最常见的三种规则算法常见场景一年实际天数ACT/365实际天数 / 365多数本币信用债、理财测算固定365ACT/360实际天数 / 360货币市场工具、部分同业固定36030/360每月按30天、每年按360天部分公司债、票息计算固定360ACT/360 和 ACT/365 的差异是 360/365 ≈ 1.39%看着不大但落在一条三年期曲线上端点能差出五六个基点做相对价值比较的时候足够让你得出相反结论。实现上我最常用的是这一个函数把规则名当参数传进去from datetime import date def year_fraction(d1: date, d2: date, basis: str ACT/365) - float: if basis ACT/365: return (d2 - d1).days / 365.0 if basis ACT/360: return (d2 - d1).days / 360.0 if basis 30/360: dd1 min(d1.day, 30) dd2 d2.day if dd1 30 else min(d2.day, 30) return (360 * (d2.year - d1.year) 30 * (d2.month - d1.month) (dd2 - dd1)) / 360.0 raise ValueError(f不支持的规则: {basis})30/360 那段里的dd2 d2.day if dd1 30 else min(d2.day, 30)是关键它处理的是起算日为31号的情况先把起算日压到30号如果压了到期日也要跟着压。这一行的写法不同市场还有细微差别有的规则不压到期日做跨市场比对时一定要跟对方确认口径别自己想当然。注意天数规则必须和票息频率配套确认。半年付息配 ACT/365 是常见组合但如果你拿到的价格是按30/360报的直接套 ACT/365 去反解YTM误差会全部堆到求解结果里而且不会报错只会给你一个看起来很正常的错误数字。2.2 计息频率与复利口径的换算同样是年化5%按年复利、半年复利、连续复利对应的实际增长完全不同。转换公式不复杂但要背下来按 f 次复利转连续复利$r_c f \ln(1 r_f / f)$连续复利转按 f 次复利$r_f f (e^{r_c / f} - 1)$半年复利转年复利$r_1 (1 r_2/2)^2 - 1$举个例子半年复利 4% 对应年复利 $(1.02)^2 - 1 4.04%$对应连续复利 $2\ln(1.02) 3.9605%$。三个数摆在一起谁也不会认错但你如果拿半年复利的数直接去年复利的公式里算一年期的误差就是4个基点五年期累积下来接近20个基点做曲线拟合的时候会明显看到近端和远端接不上。代码里我会写一对互转函数避免每次现场推导import numpy as np def to_continuous(r_f: float, freq: int) - float: return freq * np.log(1 r_f / freq) def from_continuous(r_c: float, freq: int) - float: return freq * (np.exp(r_c / freq) - 1)实际项目里我倾向内部统一用连续复利存理由很简单连续复利下多期折现就是简单相加$e^{-r_1 t_1} \cdot e^{-r_2 t_2} e^{-(r_1 t_1 r_2 t_2)}$插值、求远期、做曲线平滑都少一层幂运算出错概率低。只在最终输出报表的时候转回市场习惯的频率口径。2.3 现金流表怎么设计才不容易错一只债券的现金流本质就是一串(日期, 金额)。但工程上只存这两列不够至少要带上方向收/付和期数索引。我常用的结构是这样bond { name: 示例券A, face: 100.0, coupon_rate: 0.03, # 年化票面利率 freq: 2, # 每年付息次数 issue: date(2022, 3, 15), maturity: date(2025, 3, 15), price: 99.20, # 全价注意口径 basis: ACT/365, }然后写一个生成现金流的函数输出期数、日期、金额三列def build_cashflows(face, coupon_rate, freq, maturity, periods_left): c face * coupon_rate / freq flows [] for k in range(1, periods_left 1): amt c if k periods_left: amt face # 最后一期加上本金 flows.append({period: k, amount: amt}) return flows这段代码里我刻意没有用日期去推期数而是让调用方显式传入periods_left。原因是首期如果不是完整计息期比如起息日到首个付息日只有四个月用日期硬推容易多算或少算一期这是我在实际项目里踩过的最隐蔽的一个坑——多算一期的结果不会报错只会让YTM偏低十几个基点而且因为曲线是单调的看数字很难一眼发现。提示构造完现金流后养成一个好习惯打印一下总现金流之和和自己心里估算的本金 票息总额对一遍。这一步只要五秒钟能拦住八成以上的期数错误。3. 核心实现从价格到即期利率曲线3.1 到期收益率的数值求解给定价格求YTM没有解析解必须数值求解。先写定价函数注意这里的折现期数就是 1 到 n不需要再乘频率import numpy as np def price_from_ytm(y, coupon_rate, face, periods, freq2): c face * coupon_rate / freq cf np.full(periods, c) cf[-1] face t np.arange(1, periods 1) return np.sum(cf / (1 y / freq) ** t)注意这里的(1 y/freq) ** tt已经是期数而不是年数所以指数部分不用再乘freq。我见过不少人写成(1 y/freq) ** (t / freq)等于把折现期数又除了一次频率结果算出来的YTM大得离谱——因为价格对收益率是单调递减的除以频率相当于把整个时间轴压缩同样的价格必然对应一个更高的收益率。求解用scipy.optimize.brentq不用newton。原因很实在Brent法是区间收缩法只要两端异号就一定能收敛不需要导数牛顿法虽然快但价格函数在某些参数下导数接近零会直接发散或者跳到负利率区间外面去。from scipy.optimize import brentq def solve_ytm(price, coupon_rate, face, periods, freq2): f lambda y: price_from_ytm(y, coupon_rate, face, periods, freq) - price lo, hi -0.5, 2.0 if f(lo) * f(hi) 0: raise ValueError(区间内无解检查价格或期数是否合理) return brentq(f, lo, hi, xtol1e-12, rtol1e-12)区间取[-0.5, 2.0]是我试出来的经验值下限 -50% 足够覆盖极端折价的情况某些违约债确实会算出负收益率上限 200% 覆盖绝大多数高息场景。如果真遇到区间端点同号说明输入有问题——通常是价格填成了净价、期数算错或者票息率用了百分数3而不是0.03。3.2 Bootstrap 剥离法构建即期利率曲线这是整篇文章最核心的一块。逻辑不复杂从最短期的券开始用已知的短期贴现因子把中长期券的中间票息折掉剩下的部分就对应一个新的贴现因子从而解出新的即期利率。先看数学形式。假设半年付息第 n 期付息票息为 c面值 100$$P \sum_{i1}^{n-1} c \cdot d_i (c 100) \cdot d_n$$其中 $d_i$ 是第 i 期的贴现因子。前面的 $d_1 \dots d_{n-1}$ 已经从更短的券里算出来了所以$$d_n \frac{P - \sum_{i1}^{n-1} c \cdot d_i}{c 100}$$再由 $d_n (1 z_n/f)^{-n}$ 反解即期利率$$z_n f \cdot \left( d_n^{-1/n} - 1 \right)$$代码实现def bootstrap_spot_curve(bonds, freq2, face100.0): bonds: 按 periods 升序排列的 dict 列表字段含 periods/coupon_rate/price bonds sorted(bonds, keylambda b: b[periods]) dfs, spots [], [] for b in bonds: n b[periods] c face * b[coupon_rate] / freq pv_coupons sum(c * dfs[i] for i in range(n - 1)) df_n (b[price] - pv_coupons) / (c face) if df_n 0: raise ValueError(f第{n}期贴现因子非正检查价格或前置现金流) dfs.append(df_n) spots.append(freq * (df_n ** (-1.0 / n) - 1)) return dfs, spots这里有个df_n 0的检查别省。它意味着前面所有票息的现值已经超过了整只券的价格数学上等于要求一个负的本金折现值实际中几乎一定是数据错了——要么价格填反了要么前面某只券的期数重复了导致dfs索引错位。我拿一组自拟的示例数据跑一遍面值100半年付息券剩余期数票面利率价格贴现因子即期利率年化半年复利A10.00%98.500.9850003.046%B23.00%99.200.9627843.829%C34.00%100.300.9451423.797%D45.00%101.100.9157824.448%手工验算第二只券验证代码没错$d_1 98.50/100 0.985$$c 100 \times 3% / 2 1.5$$d_2 (99.20 - 1.5 \times 0.985)/101.5 97.7225/101.5 0.962784$$z_2 2 \times (0.962784^{-0.5} - 1) 3.829%$。对得上。这张表里有个细节值得说1.5年期的即期利率3.797%低于1年期3.829%曲线出现了一个小幅倒挂。这不是代码错了是我故意让第三只券的价格偏贵造成的——现实中新券发行溢价、流动性差异、税收因素都能造成这种局部倒挂。看到倒挂先别改代码回去核对价格来源。3.3 曲线插值从离散点得到连续曲线Bootstrap只给你离散的几个期限点但实际用的时候往往需要任意期限的即期利率。三种常用做法按复杂度和适用场景排线性插值最简单numpy.interp一行搞定缺点是曲线在节点处有折角算远期利率本质是求导时会出现跳变。import numpy as np def interp_linear(ts, zs, t_new): return np.interp(t_new, ts, zs)三次样条光滑scipy.interpolate.CubicSpline直接用远期利率连续。缺点是节点附近容易过冲特别是近端数据稀疏的时候。from scipy.interpolate import CubicSpline cs CubicSpline(ts, zs, bc_typenatural) z_new cs(t_new) fwd cs(t_new, 1) # 一阶导即瞬时远期Nelson-Siegel参数化拟合用四个参数刻画整条曲线的水平、斜率、曲度特别适合期限点很少的场合给出的是经济意义上合理的平滑曲线from scipy.optimize import curve_fit def nelson_siegel(t, b0, b1, b2, tau): x np.asarray(t) / tau return b0 b1 * (1 - np.exp(-x)) / x b2 * ((1 - np.exp(-x)) / x - np.exp(-x)) p0 [zs[-1], zs[0] - zs[-1], 0.0, 1.0] bounds ([0, -1, -1, 0.1], [0.5, 1, 1, 10]) params, _ curve_fit(nelson_siegel, ts, zs, p0p0, boundsbounds, maxfev20000)初值的取法有讲究b0是长端水平直接取最长期限的即期利率b1是长短端之差取短端 - 长端b2给0让它自己找tau给1。这个初值组合在我处理过的数据里从来没失败过。另外bounds里给tau设了下限0.1是防止$x t/\tau$ 溢出——我曾见过tau收敛到0.001np.exp(-x)直接下溢成0结果全变成常数。3.4 贴现因子与远期利率的推导有了即期曲线贴现因子和远期利率都是顺手的事def discount_factor(z, t, freq2): return (1 z / freq) ** (-freq * t) def forward_rate(z1, t1, z2, t2, freq2): d1 discount_factor(z1, t1, freq) d2 discount_factor(z2, t2, freq) return freq * ((d1 / d2) ** (1.0 / (freq * (t2 - t1))) - 1)拿上面表格的数据算一下1.0到1.5年的远期$d_{1.0}0.962784$$d_{1.5}0.945142$比值 $1.018666$年化远期 $2 \times (1.018666 - 1) 3.733%$。这个数比两端的即期都低正是前面那个倒挂造成的——远期利率对曲线斜率极其敏感这也是为什么做曲线时宁可多花点时间确认价格质量也不要事后去修远期。4. 任务收益率的几种口径与实现4.1 简单年化、复利年化、XIRR到底该用哪个任务收益率这个词在不同的台账里含义不一样我总结成三种口径各有各的适用面口径公式适用场景缺陷简单年化总收益 / 本金 × 365 / 持有天数单笔一次性投入、期限短忽略复利多笔投入无解复利年化(期末/期初)^(365/天数) - 1单笔、无中间现金流有中间现金流时失真明显XIRR解 $\sum CF_i (1r)^{-t_i/365} 0$任意时点的不规则现金流多解风险需给合理区间判断标准很简单只要中间有追加投入或者部分回款就必须用XIRR。前两种口径本质上是把整个任务当成一笔钱进出中间的钱去了哪里它完全不管算出来的数只能叫粗略参考。我拿一组自拟现金流做个对照投入15万、分两笔回收16.5万、分两笔日期现金流2023-01-05-100,0002023-07-20-50,0002024-03-1540,0002024-12-10125,000按简单年化总收益1.5万本金15万持有约705天年化 10% × 365/705 ≈ 5.18%。按复利年化$1.1^{365/705} - 1 ≈ 5.06%$。按XIRR算出来是6.25%。差了整整一个百分点以上。原因在于资金的时间权重那10万从第一天就压在里面占了全部时长后面追加的5万只压了不到一年半。简单年化把两笔钱当成同时投入低估了前一笔的贡献所以XIRR更高。做业绩归因必须用XIRR这张表我常拿来给别人解释为什么两种算法差这么多。4.2 XIRR 的实现细节def xnpv(rate, cashflows): t0 cashflows[0][0] return sum(cf / (1 rate) ** ((d - t0).days / 365.0) for d, cf in cashflows) def xirr(cashflows, lo-0.99, hi10.0): cashflows sorted(cashflows, keylambda x: x[0]) f lambda r: xnpv(r, cashflows) if f(lo) * f(hi) 0: raise ValueError(区间内未找到解检查现金流符号是否至少变号一次) return brentq(f, lo, hi, xtol1e-10)三个要点。第一现金流必须先按日期排序。XIRR的公式对顺序不敏感求和嘛但t0取的是第一笔的日期顺序乱了整个时间轴就错位。第二现金流必须有正有负而且至少变号一次。如果全部同号NPV单调区间里永远无解brentq会直接报错。这个报错信息其实很有用出现它基本等于数据里漏了一笔投入或者回款。第三lo取 -0.99 是个保险值不能取 -1。因为 $(1r)^{t}$ 在 $r-1$ 处除零取 -0.99 相当于允许 -99% 的极端亏损年化正常业务永远不会碰到。注意账面上经常出现投入记正、回款记负的符号约定跟这里的写法正好相反。导入数据前一定统一符号否则求解器会给你一个数学上正确、业务上完全错的结果——而且不会报任何错。4.3 组合收益率加权方式和调仓的影响单个任务的XIRR清楚了组合层面还有一个坑你算的是资金加权还是时间加权。资金加权也就是整体XIRR反映的是这笔钱在这个账户里实际赚了多少会受申赎时点影响在低点大额加仓会拉高它在高点加仓会拉低它。这个数适合给投资人看。时间加权TWR是把区间切成若干段每段算一个子区间收益率再连乘。它剔除了现金流时点的影响反映的是策略本身的表现适合评价管理能力。简化版的近似算法是修正Dietz$$R \frac{V_1 - V_0 - CF}{V_0 \sum w_i \cdot CF_i}$$其中 $w_i$ 是第 i 笔外部现金流在区间内的剩余时间占比。这个方法精度不如TWR但只需要期初、期末和现金流三个数台账维护成本低实务里用得很多。组合层面的XIRR最省事的做法是把所有账户的现金流合并到一张表里再求根等价于把整个组合当成一个大任务。前提是货币单位一致、日期口径一致。我见过有人把不同币种的现金流直接相加年化算出来看着挺正常实际毫无意义。5. 常见问题与排查技巧实录5.1 求解器相关的问题不收敛、报区间内无解是最常见的。排查顺序我固定成四步检查现金流符号有没有全正或全负打印区间两端的函数值看是不是同号同号说明根不在区间里或者根本没根检查价格输入是净价还是全价——净价少了应计利息反解出的YTM会偏低而且偏低得不多很难肉眼发现检查期数尤其是首期非整期的情况。结果跳到一个明显不合理的值比如YTM算出 80%。这种九成是把票息率当百分数填进去了3而不是0.03。价格函数里c face * 3 / 2 150价格才100那只能靠极低的折现因子去凑反过来解就是极高的收益率。加一个断言if not 0 coupon_rate 0.3: raise能省下大量调试时间。Bootstrap过程中贴现因子算成负数或大于1。大于1意味着即期利率为负在某些市场环境里是真实的不要急着报错小于0基本一定是错的检查前置现金流索引有没有越界。我在bootstrap_spot_curve里加的df_n 0检查就是为了拦这个。5.2 数值与口径层面的坑浮点比较。if price 100.0这种写法在算过几轮折现之后几乎永远为假。要么用abs(a - b) 1e-9要么用math.isclose。我在早期写的一个校验函数里吃过这个亏明明逻辑正确测试就是过不了查了半天才发现是 99.99999999999999 不等于 100。插值外推。np.interp在超出范围时默认返回端点值不报错也不警告。如果你拿2年期曲线去算3年期的贴现它会默默给你用2年期的利率误差全在你看不见的地方。我的做法是在插值函数外面包一层超出范围直接抛异常逼着调用方显式处理。频率不一致。票息半年付、曲线按年复利报直接混用会让远期利率算出锯齿。稳妥做法是内部全部转连续复利统一计算输出时再转回需要的频率。闰年和月末。30/360 规则里2月28日和3月1日的处理、2月29日的存在与否都会让年化因子差一天。做跨年现金流的时候务必用真实的date对象相减不要手算天数。正则解析日期。从报表里读日期时01/02/2024到底是1月2日还是2月1日取决于来源。稳定的做法是让上游固定输出 ISO 格式2024-01-02实在不行就用datetime.strptime显式指定格式别用自动推断的解析器。5.3 速查表症状最可能的原因处理方式YTM 求解无解区间不含根 / 符号全同扩大区间检查现金流符号YTM 高达 50% 以上票息率填成百分数断言取值范围即期曲线整体偏低用了净价而非全价加回应计利息曲线末端突然翘起最后一只券票息低、期限长剥离误差放大检查该券价格考虑剔除或加权远期利率剧烈锯齿插值方法不光滑换三次样条或N-S拟合XIRR 报错无解现金流全同号核对是否漏记投入或回款XIRR 结果偏离直觉符号约定反了统一投入为负、回收为正现金流期数多一期首期非整期显式传期数别用日期硬推6. 工程收尾自检、向量化与留痕6.1 用回算做自检比任何单测都实在写完一套定价和Bootstrap最有效的验证方式是闭环验证给定一组即期利率先正算出一批债券的理论价格再把这些价格丢进Bootstrap看能不能还原出原来的即期曲线。误差在 $10^{-8}$ 量级以内就说明剥离逻辑没问题。def self_check(spots, freq2, face100.0): # spots: 第 i 个元素是第 i1 期的即期利率 dfs [(1 z / freq) ** (-(i 1)) for i, z in enumerate(spots)] bonds [] for n in range(1, len(spots) 1): coupon 0.03 if n 1 else 0.0 c face * coupon / freq pv sum(c * dfs[i] for i in range(n - 1)) (c face) * dfs[n - 1] bonds.append({periods: n, coupon_rate: coupon, price: pv}) _, recovered bootstrap_spot_curve(bonds, freq, face) return max(abs(a - b) for a, b in zip(spots, recovered))这个函数里我把第一只券设成零息券因为零息券的即期利率可以直接从价格读出不需要剥离是最干净的数据源。实际业务里零息券不一定有那就退一步用最短期限的附息券当起点接受近端一点微小误差。我建议把这套自检放进 CI每次改动天数规则或者定价公式就跑一遍。浮点计算这种东西改动一处可能影响很远靠人工核对是不靠谱的。6.2 批量计算时把循环干掉单只券怎么算都无所谓几百只券、几万条现金流的时候for循环加brentq会明显变慢因为每次求根都要迭代十几次每次都重新构造现金流数组。提速的关键是预构造现金流矩阵。把所有券按最大期数补齐成矩阵用numpy一次性算折现def batch_price(ytm_vec, cf_matrix, periods, freq2): t np.arange(1, cf_matrix.shape[1] 1) mask t periods[:, None] disc (1 ytm_vec[:, None] / freq) ** (-t) return np.sum(cf_matrix * disc * mask, axis1)实测下来500只券的批量定价从原来逐只循环的 1.2 秒降到 30 毫秒左右快了将近 40 倍。求根本身没法完全向量化每只券的根不一样但可以在外层用一个列表推导加brentq配上已经预构造好的矩阵整体速度仍然能提升一个数量级。6.3 结果留痕比算得快更重要的是算得清最后说一个容易被忽略的点。利率计算这种东西半年后有人问你当时那条曲线是怎么来的如果你只能翻出一张结果表那就等于没留痕。我现在的做法是每次跑完把三样东西一起存下来输入数据含数据源和时间戳、关键参数天数规则、频率、插值方法、求解区间、结果表含每只券的反解YTM和残差。残差这一列特别有用。Bootstrap剥离出来的曲线如果拿回去正算价格和原始价格的偏差应该极小如果某只券的残差明显偏大说明这只券的价格和曲线不一致可能是数据错也可能是这只券有特殊性比如含权、流动性差。把这列留着等于给数据质量装了一个监控。另外参数一定要写进文件名或者伴随的元数据里。我踩过一次坑同一个项目跑了ACT/365和ACT/360两版结果表文件名只差一个后缀后来合并报表的时候拿错了版本整条曲线偏了3个基点查了两天才定位到。我个人在实际操作中的体会是这类计算真正的门槛从来不在数学而在口径和数据质量。公式就那么几个抄下来十分钟能背完难的是搞清楚对面要的到底是哪种收益率、价格是全价还是净价、天数规则按谁的惯例。我现在的习惯是先花二十分钟跟需求方把这些确认清楚写进注释里再动手写代码——这二十分钟能省下的返工时间通常是它的十倍以上。