develop 昨日审查
2026-06-10

玩家在同一会话内连续进两次搜打撤副本, 第二次副本开局时 _resourcePointTriggerIndexMap$$ 与 _mechanismTriggerIndexMap$$ 仍带着第一局结束时的累加值。客户端往 DeltaDungeonResourcePointTriggerReq$$.Index$$ / DeltaDungeonMechanismTriggerReq$$.Index$$ 上回填的就是旧值, 服务端按 Index 做幂等去重时把新一局所有资源点 / 机关首次触发请求识别为 "已收过的旧 Index", 整段静默丢弃。表现: 第二次进搜打撤后, 资源点 / 机关点了没掉落、机关动画卡住、背包不刷新。

271b5afbc63 在 initFromProto$$ 与 dispose$$ 两处都删掉了 _resourcePointTriggerIndexMap$$.clear() / _mechanismTriggerIndexMap$$.clear(), 加上 c5f62219a31 把 DeltaDungeonModule$$.startDungeon$$ 由 "每次 new BattleData" 改成 "复用 + dispose$$", 副本实例从此跨 raid 复用。c5f62219a31 在 initFromProto$$ 末尾只补回 _pidsInPickupRange$$.clear() 一条, 漏补两张 trigger Index Map; dispose$$ 也只清了 pidsInPickupRange。两次清理的删除动作在落锤校验时 (TODAY_TIP DeltaDungeonBattleData$$.ts L101–L113 与 L166–L186) 仍完全保留 —— Map 实例是 L95、L97 字段初始化器创建, 整个对象生命周期内 only-once。

在 dispose$$ 末尾补 this._resourcePointTriggerIndexMap$$.clear(); this._mechanismTriggerIndexMap$$.clear();, initFromProto$$ 也同步补一次双保险 (即使 dispose 漏调也能兜住)。如果服务端期望 Index 是从 1 重新计起 (与 1f920bc proto 字段语义一致), 两处都需要 reset; 如果服务端预期的是单调递增的全局 Index (跨 raid 不重置), 则需要在 startDungeon$$ 下发的 ChallengeLevelInfo 里同时下发当前 Index 基线由客户端继承, 而不是默默清零。

// DeltaDungeonBattleData$$.ts:166 (dispose$$)
public dispose$$(): void {
    this._roomDataMap$$.clear();
    this._posToRoomIDMap$$.clear();
    this._areaDataMap$$.clear();
    this._selfBuffDataMap$$.clear();
    this._pidsInPickupRange$$.clear();
    this._resourcePointTriggerIndexMap$$.clear();
    this._mechanismTriggerIndexMap$$.clear();
}

47be5e47202 把伤害上报阈值从固定 100 改成按 sourceUnit 分档 (普通 100x, 元素使者 1000x, 神农 5000x), 但 event Index ei 仍写死 keyValue >= 500 ? 6 : 17, info 字段写成 keyValue >= 500 ? max(500, reportRate) : reportRate。结果元素使者一次 1500x 触发上报时, ei=6 (按 PBC 约定 ei=6 这条流是 "≥500x 倍率档"), info="1000"; 神农一次 6000x 上报时 ei=6, info="5000"。同一个 ei=6 流里混入了 500/1000/5000 三种 info 取值, 下游分析任何按 ei 维度做的 cohort / 阈值看板都会把 1000、5000 当 500 计入。

reportRate 这条新维度只用来做 emit gate 判定 (keyValue >= reportRate), 没把 ei 跟着 reportRate 一起切到独立流; info 用 Math.max(500, reportRate) 拼凑后随便放进 ei=6 这条历史流里。"500" 既是 ei=6 的语义档名又是 info 的字面值, 混了一脚。元素使者 / 神农两段 reportRate 提升的逻辑是后加的, 与 ei/info 的旧语义没对齐。

要么给 1000x / 5000x 档分配独立的 ei (例如 ei=18 表示元素使者档, ei=19 表示神农档), info 直接传 keyValue 倍率; 要么干脆把 reportRate 作为 ei 的派生维度 (ei = reportRate >= 5000 ? 19 : reportRate >= 1000 ? 18 : reportRate >= 500 ? 6 : 17), info 传 reportRate.toString()。需要先和 PBC 数据侧对齐 ei 表的占用情况再落地。

// BaseSyncBattleData$$.ts:130 (建议修法)
let reportRate = 100;
if (sourceUnit.isElementalEnvoy$$()) reportRate = 1000;
if (sourceUnit.UnitID$$ == 86004) reportRate = 5000;
if (keyValue < reportRate) return;
const ei = reportRate >= 5000 ? 19 : reportRate >= 1000 ? 18 : reportRate >= 500 ? 6 : 17;
const info = reportRate.toString();
EventManager$$.Instance$$.emit$$(EventEnum$$.C_C$$, ei, sourceUnit.UnitID$$+"|"+result.Damage$$+"|"+atk+"|"+info, keyValue);

07e8972bce7 把 GameViewCtrl$$.Instance$$.showLoading$$(15) 与 onClose 路径里的 hideLoading$$() 都注释掉, 唯独漏了 onError 路径里的 hideLoading$$()。激励视频走错误回调时, 会去关掉一个本 commit 已经不再开的 loading 实例 —— GameViewCtrl 全局 loading 互斥栈被这次错误回调下拉一层, 实际关闭的是栈里另一个模块 (网络重连 / 资源加载 / 章节切换) 的 loading。同 commit 还在 GameNetService$$.OnConnectSuccess$$ / 断开回调里加了 this._onCloseLoadingView$$(), 与 AdInstance 这条孤儿 hideLoading 叠加, 广告失败 + 同时段网络抖动会两次跨模块关 loading。

本次需求 "卡 loading" 是为了禁掉 ad 自带的 loading, 但 onError 这条路径漏改; 全局 loading 是基于显示栈的, 没有 owner key 隔离, 任意一处 hide 就会拉一层 —— 注释式改动让漏网的 hideLoading 在静态读时显得"对称", 实际成了无源 hide。

删掉 onError 里的 hideLoading$$() (与 onClose / showLoading 注释保持配对), 或同时取消 onClose 的注释让 show/hide 重新成对; 长期建议给 showLoading$$ / hideLoading$$ 加 ownerKey 参数 (例如 showLoading$$("ad")), 关 loading 时按 key 关, 跨模块互踩从此消失。GameNetService$$.OnConnectSuccess$$ 的 _onCloseLoadingView$$() 同样需要按"自家 key" 关, 否则只是把问题推到下一个 commit。

// AdInstance$$.ts:188 (onError 路径)
let adCallback = {
    onClose(isReward, rewardAmount) {
        resolve(isReward);
        AudioManager$$.Instance$$.tryPauseThenPlayMusic$$();
    },
    onError(code, msg) {
        resolve(false);
        AudioManager$$.Instance$$.tryPauseThenPlayMusic$$();
    }
}

07e8972bce7 在 AdInstance$$ 把 // GameViewCtrl$$.Instance$$.showLoading$$(15); 整行注释保留代码; c4ac6fc37e0 在 FunctionChestPreviewView$$ 把 showLoading$$() / hideLoading$$() 两整行注释保留。注释式删除 (commented-out code) 命中 [[code-quality-baseline]] 反模式: 让后续 reader 不知道是 "临时关掉过两天还要打开" 还是 "确定不要了"; 也阻止 IDE 的 unused 检查发挥作用。同一 commit 链已经反复在跨平台 loading 上来回切, 注释残留会让下一次回滚 / 复用判断进一步发散。

commit message "卡 loading" / "华为, oppo 看广告卡 loading" 只描述结果, 不说是临时关闭还是永久删除。注释残留是 cheap rollback 留口, 但缺乏 commit message 标注就退化成噪音。

明确删除 (推荐, 代码已进 git history, 真要回滚是 git revert), 或保留时在注释行前加 // TODO(jinko, YYYY-MM-DD): xxx 平台 SDK 修好后再开, 让删除时机有明确触发条件。

// AdInstance$$.ts:183 (建议改写)
// 直接删除该行; 后续如需恢复, 走 git history 或加 ownerKey 后启用
console.log("play_ad_time$$:", Date.now());

dcabefe0468 在 DeltaDungeonBagView$$ 加了两个调试方法 _logPlacedItemDetails$$ / _getPlacedItemLogText$$, 内部直接调 console.log。项目内统一日志是 Logger$$ 系统 (有等级 / tag / 上线 strip 能力), console.log 在 release 包里不会被剥, 上生产后这条搜打撤背包刷新日志会持续打到玩家的运行时 console, 影响小程序 / 端游 console 性能, 也容易把内部字段名 (PID / 道具数量 / 槽位 index) 带到玩家可观测面。commit message 写的是 "搜打撤 1.增加背包 log", 用意是临时排查。

临时排查日志直写 console.log, 没走项目 Logger$$ 通道; 也没有 if (isDevBuild$$) 这类编译态守卫。

替换成 Logger$$.Instance$$.info$$(\"DeltaDungeonBag\", text) (或同等 tagged 接口); 排查目的达到后随 c5f62219a31 / 后续修复一并删除调用点; 短期保留也要包一层 __DEV__ / IS_DEBUG_BUILD$$ 守卫。

// DeltaDungeonBagView$$.ts (_logPlacedItemDetails$$)
private _logPlacedItemDetails$$(): void {
    if (!IS_DEBUG_BUILD$$) return;
    const text = this._getPlacedItemLogText$$();
    Logger$$.Instance$$.info$$("DeltaDungeonBag", text);
}