财报发布后如何重跑选股：只更新受影响的公司和条件
财报发布后，不一定要重跑整张股票池。先取得已审核实绩字段，再按规则依赖找到对应公司的受影响条件，重算之后说明名单是否变化。交付应包括接受了哪份公告、改了什么字段、实际执行哪些条件以及哪些结果被复用。日历显示“今天预计披露”，并不能证明正式结果已公开，更不能授权写入新财务值。
本文提供合成年报数据驱动的本地函数，不监听交易所、不提取任意PDF、不启用Vibe调度，也不调用模型。它演示经过审核的发布事件如何接入一个局部更新流程。CoTrading是否能够收集公告、验证财务数或维护实时名单需要另行实现和核实，不能从独立脚本的成功推导出来。
区分发布事件与财报日历提醒
从发行人或合适的正式披露来源取得实际发布记录，保存证券、事件标识、公开时间、来源引用、财年和字段验证状态。预计日期只能提醒去检查公告，不能提供真实发布时间，也不能直接给出实际EPS。事件schema中要保留这种差别，不要把计划任务抵达时刻自动填成财报已发布时刻。
SEC EDGAR接口文档描述了提交记录随披露传播而更新，可用于说明实际传播记录与预定日历的区别。本文不调用SEC，也不把EDGAR当A股公告源。实际A股流程需要另外提供合适的正式披露适配器，并审核报告字段到本地筛选指标的映射，不能仅换一个网址就宣称跨市场完成。
合成事件类型为official_release，verified必须是真布尔值true，公开时间2026年10月26日UTC+08的15:30，研究决策时间当日16:00。字段为2026财年年度稀释EPS和相同年度增速，币种人民币。虚构公司的该财年已经结束，因此没有把九个月累计EPS直接塞进年度PE规则；真实公司必须单独检查财年起止。
先写依赖表，再接收变更
现有筛选包含三条条件：估值依赖price和eps，正EPS条件下价格除EPS小于20；增长依赖growth，要求至少10%；流动性依赖turnover，要求至少2，单位沿用已确认数据合同。依赖是明确字段集合，事件改变哪些字段，就机械地映射到哪些条件，不能靠模型最后说“相关规则已更新”来证明。
如果将来规则依赖行业排名或同行分位数，一家公司变化可能影响多家排名，依赖范围需要扩大。本文仅使用公司本地条件，所以局部更新在这个范围内成立。不能从本例推广出“所有选股条件都只需重算一家公司”。先说明规则传播范围，再决定哪些结果有资格复用，避免无形依赖让缓存结果过期。
旧快照AAA价格18、EPS1、年度增速8%、换手字段3，估值和流动性通过，增长不通过；BBB价格16、EPS1、增长15%、换手3，三项都通过，初始名单只有BBB。它们是已提供的筛选观察值，盈利期间由筛选合同固定，不靠公告标题猜测。要更换实际、预告或预测口径时，另行审核整个规则含义。
事件先验收，再暂存候选结果
计划事件、未验证字段、未来公开时间、错误财年、币种或稀释口径、不存在来源标识，都不能进入更新。Python datetime支持带时区的可得时间比较。文本"true"不能替代布尔值true，避免某个字符串转换恰好绕过验证门槛；但这个门槛仍只代表接受外供验证状态，不代表脚本亲自审核公告。
样例只允许事件修改EPS和growth，所有数值在去重和修改前先验有限性。Python Decimal可表示NaN和无穷，因此必须额外拒绝。估值还要求价格、EPS为正。亏损公司应有明确不适用或未知政策，不能让负PE因为小于20就自动满足低估值要求。
先在候选公司行上合并字段，算出候选条件结果，全部通过才替换本地行、条件表并消费事件键。任何失败都保留原数据、原条件和去重状态。这样可以避免EPS已经写进去、增长还没验证就报错，留下半更新名单。断言要核对完整状态不变，不能只看函数抛了异常便认为没有副作用。
仅执行两条实际受影响条件
AAA正式事件将EPS改为1.2，增速改为12%，价格仍18、换手仍3，因此估值比率15、增长也通过。变化字段只有EPS和growth，依赖表选出估值与增长，不调用流动性；BBB整行和三项条件都不动。最终名单变为AAA、BBB，新增原因能够回溯到这次正式财报更新。
实际调用表按确定顺序记录AAA:growth、AAA:valuation。程序在更新前深复制BBB数据与条件，更新后比较完全相同，同时断言调用名单。这比只检查最终候选更有力，因为即使错误地重算所有公司，最终名单也可能一样。局部执行的承诺需要通过调用证据验收，不应靠结果巧合推断。
affected = sorted(
name for name, fields in DEPENDENCIES.items()
if fields & set(event["fields"])
)下载完整示例。使用Python 3.12+、标准库和合成数据，运行python R551.py。输出主例、实际调用、未变BBB、重复事件和阻断原因，不创建监听器、定时器、消息发送器或交易连接。
重复事件与内容冲突不能混为一谈
去重键采用证券加事件ID，同一个简短ID可以出现在不同公司命名空间中。键旁保存已审核内容的规范化表示。原样重复AAA事件返回duplicate_suppressed，没有规则调用；同证券同ID换成另一个EPS则抛conflicting_event_id，不能让最后到达的行覆盖已接受版本。没有发布顺序证据时，不能猜哪个数更新。
真实发行人更正可能完全合法，但需要新的已审核更正标识或明确版本政策。否则延迟抵达的旧载荷可能反向覆盖更新数据。冲突应保留来源并转人工核对，失败事件不能消耗成功状态。示例去重仅在单进程内存，不保证并发工作器与重启后的严格一次执行；扩大到持久系统必须另加协调。
回放不能更新的事件
把类型改scheduled_release，即使附带看似合理EPS，也在写入前拒绝。把公开时间改为10月27日，在26日决策时点同样拒绝。文本验证标记和内容冲突又是独立原因。完整脚本逐次保存更新前状态，异常后断言数据、条件、去重表都没有变化，证明阻断真正发生在提交之前。
有限数测试则覆盖另一机制：事件格式和公开时间都正确，数值仍可能无效。日志应区分公告未确认、字段错误、合法更正待审核等问题，以便指向正确补查步骤。泛泛写“更新失败稍后再试”不能告诉用户需要等待发布、修正字段还是解决版本冲突，也容易触发没有意义的重复请求。
保留变化记录并定义后续失效
最终交付来源事件、接受字段、旧新值、受影响条件、实际调用与新旧成员关系。价格以后变化，应通过price依赖让估值失效；财报事件不能声称顺便刷新了行情。规则版本、单位或会计口径改变时，重新考虑所有受影响行，不能只处理最后收到公告的那家公司。依赖表使这些动作在启用自动化前就可审阅。
还需区分没有变化和没有执行：正式公告更新某个字段后，规则可能重算但布尔结果仍相同，这也是成功更新；重复事件则根本没有新调用。记录旧新字段、调用和条件值三层，才能解释名单为什么保持不变。若新公告只包含不支持字段，应明确拒绝或交给另一个已定义任务，不能消费事件后悄悄不做任何事。
保持局部更新的来源边界
公告字段与行情字段应分别标来源。AAA价格18在本例保持不动，代表已有筛选快照，不是财报事件顺手取到的新价格。真实运行若这份价格已经过期，应先按行情政策刷新再重算估值，不能因为EPS更新成功就忽略价格时点。局部依赖让重算范围变小，但不会让所有未变化输入自动永久有效。
接受某事件前还要确认它针对哪项任务合同。正式年报、业绩更正、预告和季度累计可能都来自同一公司，却不一定能写入同一个年度EPS字段。来源正式只解决发布真实性的一部分，期间与指标映射仍需审核。本文只有已审核年度字段，未提供这些文件类型的通用分类器，不能把验证标记理解为机器已完成所有会计判断。
实际事件到达顺序可能落后于公开顺序，多个合法公告也可能同时待处理。本例只演示一次正式更新和同ID冲突，不提供跨事件自动择新政策。扩展时先定义更正关系、版本排序和受影响范围，再批量执行；资料不足时保留待核而不是猜新旧。这样重复抑制和合法修订各自有明确入口，不会互相绕过。
常见问题
预计财报日可以触发财务替换吗？
可以触发检查公告的动作，不能替代真实发布事件与已核实字段。
一家公司披露后必须重算所有股票吗？
取决于规则依赖。本例是公司本地条件，且通过断言验证BBB不受影响。