同一函数内第二次Firestore更新调用未执行问题排查

• 最核心的逻辑错误：第一个try块中commanders集合更新成功后，代码直接执行了return true，会立刻终止当前函数的执行，后续针对players集合的更新代码永远没有运行机会，这就是你观察到commanders更新正常、players逻辑被跳过的直接原因。
• 潜在隐藏问题：Firestore的updateDoc方法要求目标文档必须已存在，否则会抛出异常。你实现的addPlayer用的是setDoc创建文档，如果对应playerName的players文档还没被提前创建，就算调整了return位置走到第二个更新逻辑，也会因为文档不存在抛错，被catch块捕获后仅打印日志、没有显性提示，看起来也会像逻辑被跳过。

如果你的需求是两个文档的更新都要执行，不要在第一个更新完成后就return，把两个更新逻辑放在同一个流程里，等所有操作完成再返回结果。如果不确定目标文档是否存在，可以用setDoc搭配merge: true选项，实现文档不存在则创建、存在则更新字段的效果，避免updateDoc的文档不存在报错：

if (commander && outcome) {
    try { 
        // 更新指挥官数据
        await updateDoc(doc(db, 'commanders', commanderName), {
            Wins:  commander.Wins + 1,
            Games: commander.Games + 1,
        })
        // 更新玩家数据，两个操作都完成后再返回
        await setDoc(doc(db, 'players', playerName), {
            Wins:  player.Wins + 1,
            Games: player.Games + 1,
        }, { merge: true })

        return true
    } catch(e) {
        // 不要静默吞错，打印完整错误方便定位
        console.error('对局数据更新失败：', e)
        return false
    }
}

如果你需要分开处理两个更新操作的错误，也不要在第一个try块中直接return，等两个逻辑都执行完成后再统一返回。

• 断点调试：直接在players更新逻辑的代码行号左侧点击，打一个红色断点，按F5启动调试模式运行对应逻辑，你会发现这个断点完全不会被命中，调试器会在第一个try块的return语句位置直接跳出函数。
• 日志标记：在第一个try块的return语句前、两个try块之间分别加打印语句，比如console.log('指挥官更新完成，即将返回')，运行后看控制台输出就能明确代码的执行路径，确认是不是提前return了。
• 错误排查：如果调整return位置后还是无法正常更新，把catch块里的打印改成console.dir(e)输出完整错误对象，Firestore的报错信息会明确标注是权限问题、文档不存在还是参数错误，直接根据错误信息排查即可。

内容的提问来源于stack exchange，提问作者Cole Perry