财报数据更正后怎么办：找出受影响的选股与公司估值结果
财报数据更正后，应先撤销所有依赖该输入的当前研究结果，再执行重算。沿数值依赖追踪影响，保存原研究版本，只重跑真正受影响的计算。资料夹里多了一份更正公告，或者链接已经修好，并不证明旧筛选和估值已经采用新数字；不能让旧结果继续冒充最新。
本指南执行一个小型依赖图，使用虚构公司和刻意简化的估值情景，不监控互联网公告、不操作券商账户，也不证明CoTrading已有自动依赖追踪。更正值与来源身份必须先由研究者核实。历史研究快照保留原信息集，与正在更新的当前视图分开。
用完整身份接纳一次更正
至少记录公司、指标、报告期间、单位、原输入引用、更正后值、更正事件身份和支持来源。下一年度的新数据并不自动更正上一年度；会计基础变化也可能要求建立新模型，而不是直接替换一个数字。先理解来源关系，才能决定哪些计算真正应变。
事件还应声明预期替换的旧值，防止修改已经前进到另一版的状态。本例预期A收入为一百二十，将其改为一百零五。若活动状态的旧值不符，停止并回查，不要猜测这一更正想对应哪一个历史版本，否则输入和审计轨迹会一起失真。
更改状态之前验收新输入。本例窄收入模型要求已知输入键、来源引用以及有限正数。Decimal有限数检查只能帮助检查数值，不能验证财报原文。它没有实现所有更正类型，例如另一模型中可能合法的负自由现金流，需要另定义规则，不能机械套用正收入门槛。
明确登记真正读取的数值依赖
把每个计算连接到它实际使用的输入或上游结果，而不是只登记文档之间的链接。合成图如下：
| 结果 | 直接依赖 | 含义 |
|---|---|---|
| A_growth | A_revenue、A_prior | 收入增长 |
| A_screen | A_growth | 增长至少10% |
| A_value | A_revenue、margin、discount | 声明的现金流情景 |
| A_brief | A_screen、A_value | 组合研究交接 |
| B_growth | B_revenue、B_prior | B的增长 |
| B_screen | B_growth | B的入选状态 |
| B_value | B_revenue、margin、discount | B的情景值 |
这里的期间与币种单位已经约定一致，节点也按有效执行顺序排列。它不是从任意笔记本自动抽取依赖的工具。真实工作表若还用收入估计营运资本，就必须加入相应依赖；漏掉一条边，即使已有节点全部重跑，也不能宣称更新完整。
影响应沿间接关系扩展。收入更正直接影响增长和情景值，间接影响筛选及摘要。只在文字里搜索旧数字，未必能找到这些关系，因为计算可能使用输入却没有把它打印出来。维护明确的输入到结果注册表，才能让局部重算有可核对的范围。
把报告事实与估值假设分开
A原收入一百二十、上期一百，增长为百分之二十，达到至少百分之十的筛选条件。情景模型另行假设：投入后自由现金流率固定百分之十，贴现率百分之十，永久零增长。计算为收入乘现金流率再除贴现率，原结果一百二十，与收入使用同一货币规模。
这是一项明确自设情景，不是会计恒等式。报告收入并不能证明自由现金流就是收入的百分之十，真实估值还需要经营、税项、投资和营运资本假设。例子没有输入股数，所以一百二十不是每股目标价，也没有给真实股票作估值建议。
更正确认后一百零五使增长变为百分之五，筛选转为失败，情景值变成一百零五。这个算例只隔离一项输入，在现金流率和贴现率不变的条件下追踪变化；它不测量现实股价如何响应更正，也不从候选名单退出推出卖出结论。
先失效，再执行受影响队列
程序反复扩展依赖前沿，直到没有新增节点。保存原输出后，更新输入版本，将四个受影响结果标为待更新，并清空其当前值。这个间隔调用read_current('A_screen')会报错。不能在新收入已经到达时，仍把旧的“通过”交给下游排序或摘要。
关键失效闭包为：
affected, frontier = set(), {changed_input}
while frontier:
newly = {node for node, deps in DEPS.items()
if node not in affected and set(deps) & frontier}
affected |= newly
frontier = newly随后按已声明顺序计算增长、筛选、情景值和摘要。上游不是当前有效，下游就保持阻断。相比在旧数旁贴一条警告却继续使用它，这种状态规则能真正防止旧值混入新版本。真实系统若动态增加节点，还必须另验执行顺序及循环依赖，本例没有实现通用调度框架。
历史版本也必须是独立对象。Python复制文档说明了嵌套状态复制涉及的区别。本例活动输出更新时，保存的历史快照不会跟着改变；但内存复制不等于数据库事务、持久保存或防篡改，生产存储要另做验证与权限设计。
实际复现候选和情景值变化
下载完整示例，使用Python 3.12或更新版本运行python R559.py，只需标准库。断言核对真实计算、失效期间和故障分支，而不是只修改文件的“最新版”标签。
| 项目 | 更正前 | 成功重算后 |
|---|---|---|
| A增长 | 20% | 5% |
| A筛选 | 通过 | 失败 |
| A情景值 | 120 | 105 |
| 候选名单 | AAA、BBB | BBB |
| B增长与情景值 | 约11.1111%、200 | 保持 |
实际队列只有四个A节点。B的值、状态和版本不变，也没有执行重算。程序还比较保存的历史对象与原输出，明确断言候选从AAA、BBB变为BBB。由此得到的是可执行计算变化，不是一份没有核算内容的来源替换登记。
同一更正重放返回空影响集，不产生新的计算；同一事件身份却改变内容则是冲突。重试不能伪装成第二次财务更正，也不能悄悄重新解释一个已经处理的事件。保留这些区别，才能在重复通知或任务重启后仍追溯一次真实变化。
故障之后保留有用的部分结果
不同机制反例让A_value在增长和筛选完成后失败。新筛选仍为当前且失败；估值没有当前值，摘要则标blocked_dependency。不能把旧一百二十回填，和新收入、新筛选放在一起冒充同一套已完成版本。
B没有受影响，仍可使用。一个计算失败不必丢弃全部研究，但交接时必须分开当前、待更新、失败和依赖阻断。继续运行应沿更正后的输入版本重试失败分支，保留失败尝试，不把更正前快照恢复成所谓最新结果。新事实已经确认，计算失败不能让它自动失效。
验收当前研究视图
先核对更正身份、预期旧值和来源，再重建影响闭包，与实际队列逐项比较，并挑一项不受影响结果检查。确认历史快照可取，每个需要更新的当前结果都引用新版本；对于失败节点，要能看出为何没有当前值以及下一次允许执行的条件。
模型逻辑改变时还需重查依赖注册表。新的现金流率公式可能同时读取两家公司，使原本局部的变化变成非局部。诚实记录这些边，即使在表格里也有用；所有修改都全量重跑会掩盖依赖问题，不检查就把所有修改叫局部更新，则会留下看不出的旧结果。
用未更正公司作为对照组
更新AAA时，把BBB保留为对照组。其增长、筛选和情景值不仅数字不变，版本与有效状态也应保持不变。这个检查可以区分真正的局部重算与把所有记录重新生成后恰好得到近似结果。没有对照组，程序可能扩大影响范围却仍然通过几条最终数字断言。
同时单独读取归档快照。当前视图更新以后，归档中的AAA仍应保留更正前收入与当时的候选判断，否则历史研究会被后来的信息覆盖。深复制只是本例隔离内存对象的方法；实际数据库还需要不可变版本、事务或相应发布机制，不能把内存示例等同于完整存储保证。
再模拟估值节点失败。此时增长和筛选可以完成，但摘要依赖没有完成的估值，应保持阻断。发布层必须检查状态，不能从历史快照找一个旧值填回当前字段。部分成功需要逐节点表达，整体成功标记无法准确描述这种情况。
最后核对候选列表确实从两只变成只剩BBB，而不是只改变某个筛选布尔值却没有更新最终可读产物。研究任务的验收应落实到用户实际看到的候选和计算结果。
常见问题
修好来源网址就算重算完成吗？
不算。先确认数值是否改变，撤销真正依赖它的结果，再核对新执行的计算。
更正后是否重写所有历史版本？
不应重写。历史快照保留原信息集，当前视图在明确的新更正版本下更新。