阶段4C2收线取消缺陷修复方案独立审查

2026-09-24。审查对象：《阶段4C2收线取消缺陷最小修复方案-待评审-2026-09-24.md》（sha256 47CF3AFA…FB1，本次hash核对一致）。独立只读审查，未改动任何生产代码、共享文档或测试；未运行Unity、未连接任何服务器/账号。

一、审查范围与方法

通读方案与《阶段4C2第二次真实尝试与收线取消记录-2026-09-24.md》，并以 run 62216 一手证据复核：KVGameplayLoopTests/runs/62216_639258472117601499/events.jsonl 全时间线、diagnostic-impl/run62216-final-state.json（error="Fishing reward cancelled: controller disabled"）。
逐行核对源码：Client/Assets/Scripts/Services/UserService.KVFishingReward.cs（FishingRewardAction :26-40，字段 :36；BeginRewardEnding :167-175；BindRewardPanel :176-187；RewardCurrent :188-189；BeginRewardSegment :203-211；ConfirmRewardAsync :242-275；PresentReward :276-280；CancelReward :281-287）、FishingUpdateSys.cs（Update→FishEnd :1225-1228；FishEnd :1247-1263；ShowKVRewardPanelAsync :1265-1273；FishEndCore :1275-1380；OnDisable :3200-3213；OnDestroy :3250-3259）、UserService.KVGameplayLoop.cs（CancelFishing :192-198；Revoke/CloseAsync :278-279；Fault :281-291）、FishingRewardPanel.cs（OnDisable :36；ConfirmKVRewardAsync :25-35；OnShow绑定 :340-364；OnDestroy :1177-1180）、UserService.KVFishingRewardValidation.cs 全文、FishingBehaviorB.cs（BeginFishing(this) :767；CancelKVFishing :34；OnDisable/OnDestroy :2436-2439/:2462-2465）、QuitAct.cs（CloseAsync排水 :35-38）、UIManager.cs（DestroyUI，GameObject.Destroy :938）、FishingDuelAct.cs:168。
全库grep核对 CancelReward/CancelFishing/BeginRewardEnding/BeginRewardDrawing/BeginFishing/DestroyUI(FishingPanel) 的全部调用方，确认守卫影响面闭合。
按 KVFishingRewardTests/controller-cancel-fix-review-hashes.json 以 SHA256（大写hex）+字节数逐项核对10个文件（工作目录 C:\projects\ft，python只读计算）。
以最近一次全绿固定验证 KVGameplayLoopTests/reward-fixed-runs/20260924T092707_*/result.json 核对"43组168断言"基线（实测 success=true, groups=43, assertions=168，与方案一致）。

关键实证（对裁决最重要的一条）：events.jsonl 时间线为 11:54:00.766 第4次special-skill-check（即BeginRewardEnding→CheckRewardContext→CheckRewardGuide 的审计）→ 11:54:00.768 fault("controller disabled")（即FishEndCore内DestroyUI(:1312)同步触发OnDisable(:3203)→CancelReward）→ 11:54:00.780 fishing-reward-segment {segment: ending}（using块仍正常Dispose，证明CancelReward只Fault不抛出、故障确发生在"ending"段内部的自拆除）。这把记录文档中"瞬时禁用来源尚未定位"的旧假说否定掉：禁用源就是完成路径自身的 FishEndCore 拆除，方案的诊断成立。

二、hash核对表（10项）

工作目录 C:\projects\ft；算法 SHA256，大写hex；字节数一并核对。

#	文件	结果	字节数
1	Client/Assets/Scripts/Services/UserService.KVFishingReward.cs	一致（3104B335…4101）	20005/20005
2	Client/Assets/Scripts/Services/UserService.KVFishingRewardValidation.cs	一致（14827CA2…C6EA）	41479/41479
3	Client/Assets/Scripts/Services/UserService.KVGameplayLoop.cs	一致（930D1FF0…B4A）	40556/40556
4	Client/Assets/Scripts/GampPlay/FishingB/FishingUpdateSys.cs	一致（937EF7EC…0CA3）	130654/130654
5	Client/Assets/Scripts/UI/FishingReward/FishingRewardPanel.cs	一致（5289088D…9789）	58984/58984
6	CodexOutput/upserver/阶段4C2第二次真实尝试与收线取消记录-2026-09-24.md	一致（4A4D735F…AAF1）	5232/5232
7	CodexOutput/upserver/阶段4C2收线取消缺陷最小修复方案-待评审-2026-09-24.md	一致（47CF3AFA…3FB1）	4410/4410
8	KVFishingRewardTests/diagnostic-impl/run62216-summary.json	一致（49736290…BEDC）	1924/1924
9	KVFishingRewardTests/diagnostic-impl/run62216-final-state.json	一致（F927149D…C27）	847/847
10	KVGameplayLoopTests/runs/62216_639258472117601499/events.jsonl	一致（7F637600…43A）	4231/4231

10/10 全部一致。 该清单同时把5个源文件当前状态钉死，可作为实施后"其余文件字节不变"判据的比对基准。

三、六个审查重点逐项回答

重点1：守卫是否精确覆盖且仅覆盖"FishEndCore拆除窗口"

拟议守卫插入位置（身份守卫 :284 之后、a.Cancelled=true :285 之前）正确；用 ReferenceEquals（而非Unity伪null==）对已销毁托管引用判定也正确。四种情形逐条核对：

(a) 战斗中（Ending=false）控制器disable：新守卫因 a.Ending==false 不生效 → 原逻辑 a.Cancelled=true 且 Ready && !a.Confirmed → Fault（KVFishingReward.cs:285-286）。真实放弃保护保留，结论成立。但注意：现有43组中没有任何用例钉住这条（见重点4/问题P2-1）。
(b) Ending后Confirmed前的控制器disable/destroy（缺陷窗口）：守卫返回、不取消。run 62216 实证该窗口内控制器disable的唯一已知来源就是 FishEndCore 自身的 DestroyUI(:1312)（堆栈+events.jsonl时序，见第一节）。全库仅两处销毁 FishingPanel：FishEndCore:1312 与 FishingDuelAct.cs:168；后者为对决路径，而对决在准入处即被拒（CheckRewardEnvironment :117-119 Stop），rewardAction 不会存在，不构成豁免漏洞。
(c) Confirmed后控制器disable：守卫因 !a.Confirmed 不满足而不适用 → 照旧 a.Cancelled=true，且 :286 的 !a.Confirmed 使其不Fault——与既有用例"confirmed-normal-cancel-no-second-exit"（Validation :120-122，断言 Cancelled && fishingAction.Cancelled && Faults==0 && Ready）完全一致。该用例中 CancelReward(rewardAction.Controller,"normal disable") 正是 Controller 身份、但 Confirmed=true，守卫不改变其期望。结论成立。
(d) Panel与Consumption.Actor路径：守卫要求 ReferenceEquals(actor,a.Controller)。Controller 是 FishingUpdateSys（BeginRewardDrawing(this)，FishingUpdateSys.cs:531），Panel 是 FishingRewardPanel 实例，Consumption.Actor 是 FishingBehaviorB（BeginFishing(this)，FishingBehaviorB.cs:767）——三者在真实游戏与验证harness中均为互不相同对象，守卫对 (d) 永不触发。既有"actual-panel-disable-pending"（:229-242）与"cancel-after-consume-before-reward-confirmed"（:116-119）不受影响。结论成立。

结论：精确覆盖且仅覆盖缺陷窗口，四情形全部与方案论断一致。

重点2：FishEnd开始后的真实退出/放弃路径，守卫是否错误放行

Ending=true 之后会调用 CancelReward(Controller) 的路径，全库grep仅两条：FishingUpdateSys OnDisable(:3203) 与 OnDestroy(:3253)——即被豁免的恰是完成路径自拆除本身。真实放弃不依赖这两钩子：

合法放弃主通道：CancelFishing(action) → CancelReward(action.Actor)（KVGameplayLoop.cs:195）。actor=FishingBehaviorB ≠ Controller → 守卫不豁免 → 照旧取消（未Confirmed则Fault）。调用方：FishingBehaviorB.OnDisable/OnDestroy（:2439"disabled"/:2465"destroyed"，场景/演出对象拆除、编辑器停止时触发）、抛竿tween被杀（:41，仅战斗期）。
QuitAct排水：QuitAct.cs:35-38 CloseAsync() → Revoke()（Ready=false，KVGameplayLoop.cs:278-279）→ 在途 ConfirmRewardAsync 的 !RewardCurrent(a) 检查（:257/:266）失败 → Stop/Fault。用户退出到主页/登出在ending窗口内仍被拦截。
Panel路径：FishingRewardPanel OnDisable(:36)/OnDestroy(:1180)，不受守卫影响（重点1(d)）。

结论：不存在只经 FishingUpdateSys disable/destroy 表达的真实放弃场景；守卫不会错误放行任何真实退出。 残余风险提示（非本方案缺陷）：Ending=false 期间若存在非退出性的"瞬时禁用"控制器（记录文档的旧假说，本次实证未支持、堆栈已否定），仍会按4C2原语义取消+Fault——维持原状，未被实证，不在本次最小修复范围。

重点3：OnDisable/OnDestroy两钩子覆盖与帧尾Destroy时序

两钩子（:3203/:3253）都传 this（Controller），守卫对两者同样生效——都覆盖，且都应覆盖：UIManager.DestroyUI 用 GameObject.Destroy（UIManager.cs:938，帧尾销毁）。run 62216 堆栈与events时序证明 OnDisable 在 DestroyUI 调用内同步触发（.768 fault 先于 .780 段Dispose）；OnDestroy 延迟到帧尾，同一帧内 Confirmed 不可能为 true——确认必须经 ConfirmRewardAsync 的 FlushKVAsync+票据等待（:253-270，30秒预算的真实网络往返），而确认链在 FishEndCore 返回、ShowUI 面板 OnShow(:347 BindRewardPanel) 之后才启动，物理上晚于帧尾。故正常流中两钩子均落在 Ending && !Confirmed 窗口内，守卫全覆盖。
假想边界（OnDestroy晚于Confirm完成）：守卫因 Confirmed=true 不适用 → 落入原逻辑置 Cancelled、不Fault（:286）——与既有"confirmed-normal-cancel-no-second-exit"钉住的"确认后取消不二次退出"语义逐字一致，不产生新行为。结论：与既有语义一致。

重点4：新增验证用例设计充分性与既有43组168断言影响排查

红（现状：pre-confirm控制器disable→Cancelled+Fault）：既有代码路径 :284-286 直接可推，且 run 62216 已是实证红。绿（守卫后：不取消、Ready保持、后续确认展示可完成）：守卫后 Cancelled=false，RewardCurrent(:188)链路完整，BindRewardPanel→reward段→ConfirmRewardAsync→PresentReward 均可走完（见重点5）。红绿主边界成立。
Confirmed后语义：既有组 :120-122 原样保留即可覆盖，方案已声明。Panel未决语义：既有组 :229-242 覆盖。Consumption.Actor路径：既有组 :116-119 覆盖（该组若守卫被误写宽到Consumption.Actor会失败，恰好是防回归点）。
未覆盖的边界（问题P2-1）：Ending=false 时 Controller disable 仍取消+Fault——方案的核心保留承诺之一，但既有43组与新增组都没有钉住。逐一排查验证中全部 CancelReward/CancelFishing 调用点（:118 actor=Consumption.Actor；:121 Controller但Confirmed=true；:237 panel），确无任何用例以 Controller 身份在 Ending=false 时调用 CancelReward。若守卫被误实现（如漏写 a.Ending 或写成 !a.Confirmed 即返回），全量验证仍会全绿。应在同一Validation改动里补一组对照（如 battle-controller-disable-still-cancels：不置Ending，CancelReward(Controller)→断言 Cancelled && Faults==1 && !Ready）。
既有43组168断言：如上逐点排查，三个调用点的actor身份/时序均不落入守卫，零期望变化。43/168基线经最近全绿result.json核实。

重点5：守卫生效后 ShowKVRewardPanelAsync/BindRewardPanel 流程可否走通

可以。逐步核对：FishEnd :1254 BeginRewardEnding 置 Ending=true（:172）→ using BeginRewardSegment("ending") FishEndCore() → DestroyUI(:1312) → OnDisable → 守卫返回（Cancelled保持false）→ FishEndCore KV分支 :1355 提前return（由wrapper开UI）→ using正常Dispose（events.jsonl .780已证明）→ ShowKVRewardPanelAsync(:1265) → ShowUI → 面板OnShow(:340) → BindRewardPanel(:347)：要求 RewardCurrent(:188，!Cancelled ✓ 且 FishingCurrent(Consumption) ✓) 与 a.Ending ✓ → Applying/Panel置位 → "reward"段写入(:351-356) → ConfirmKVRewardAsync(:25) → ConfirmRewardAsync（Sealed→票据→Confirmed :271）→ PresentReward(:276)：要求 Confirmed ✓ → 展示。所有门条件在守卫下均满足；run 62216 同场景修复后将走到面板而非fault。

重点6：静态diff判据与验收组合是否足够

足够且可机械化执行：(1) 全量固定验证重跑是行为门；(2) Editor 0错误 + SERVICE_HOST exit 0 是编译门（KVFishingReward.cs 整文件在 #if UNITY_EDITOR && !SERVICE_HOST 内，两态都需验证）；(3) 静态diff最小性可对照本审查第二节的hash清单执行——未改动文件（FishingUpdateSys.cs/FishingRewardPanel.cs/KVGameplayLoop.cs等）必须保持清单中的hash不变。建议补充（P3-2）：实施记录中固化修改后两文件的SHA256，并归档新增组的红测失败证据（修复前运行result），使红绿两侧都有落盘凭证。

四、问题列表

P1（阻塞）：无。

P2（应修，随拟改动2同一Validation改动落实）：

P2-1 新增验证组缺少"战斗中（Ending=false）控制器disable仍取消+Fault"的对照用例。这是方案明示保留的真实放弃保护，目前无任何固定验证钉住；缺失时守卫若被误写宽（漏 a.Ending 条件等）全量验证无法发现。补一组 battle-controller-disable-still-cancels（构造rewardAction不置Ending → CancelReward(rewardAction.Controller,…) → 断言 Cancelled && Faults==1 && !Ready）。

P3（建议，不阻塞）：

P3-1 绿用例中在守卫豁免第一次disable后，再补一次 CancelReward(rewardAction.Controller,"controller destroyed") 模拟OnDestroy第二钩子（:3253），钉住两钩子同被覆盖（与OnDisable走同一守卫分支，风险低，成本一行）。
P3-2 验收判据补充：实施记录固化修改后 UserService.KVFishingReward.cs 与 Validation 两文件的SHA256；归档新增组在修复前的红测失败result。
P3-3 方案文字"BeginRewardEnding 成功后"在验证harness中不可直接照做：harness 的 rewardPlan 无 Data，真实 BeginRewardEnding 的 CheckRewardContext 会NRE；应按 Batch() 模式直接置 rewardAction.Ending=true（Validation :64），或按 :253/:295 组模式构造 rewardPlan.Data。实现细节，不影响设计。
P3-4 方案对 KVFishingReward.cs 的个别行号引用有漂移（RewardCurrent 实为 :188 非 :183；BeginRewardSegment 实为 :203 非 :198；ConfirmRewardAsync 实为 :242-275；CancelReward 为 :281-287）。关键锚点（守卫位置、OnDisable:3203、OnDestroy:3253、DestroyUI:1312、KVGameplayLoop:195）全部准确，hash绑定为准，不影响结论。

五、最终结论

有条件批准实施。 条件（1项，P2-1）：拟改动2的新增验证组必须同时包含"Ending=false控制器disable仍取消+Fault"的对照用例，与主红绿用例同批落盘。其余按方案执行：拟改动1的一行守卫经四情形、真实退出路径、双钩子时序、面板流程、既有43组逐点排查均验证正确；拟改动2按P3-1/P3-3建议微调实现方式。验收按方案四条执行，并以本审查hash清单作为"其余文件字节不变"的比对基准。不构成4C2关闭。

六、边界声明

本审查为静态只读审查＋离线hash/证据核对，未运行Unity、未执行任何固定验证、未连接正式/测试服务器与账号；不构成对修复后行为的运行验证。
本审查的"批准实施"仅授权方案限定的两处代码改动进入实施流程；修复后的真实收鱼闭环、新进程恢复仍需用户另行授权，4C2/完整4C/G4均不因此关闭。
run 62216 消耗的10点体力不补发/不退款/不重放的既有约束不变。

15 KiB Raw Blame History Unescape Escape