我在批处理循环里写了 try except pass,觉得出错就跳过别让程序崩很稳健,结果一批数据悄悄少处理了一半还谁都不知道,连 Ctrl+C 都按不停:一次裸 except 吞掉异常的深度复盘

我有个批处理循环处理一批数据,为了健壮给循环体包了 try: ... except: pass(出错就跳过继续)。可线上跑完对账发现处理结果悄悄少了一大半:本该 1 万条只成功几千条,另外几千条出错被 except: pass 静默吞掉跳过、没有任何日志和报警谁都不知道;更离谱的是跑的时候 Ctrl+C 想停居然按不停。查清才明白用裸 except + pass 的两宗罪:pass 把异常静默吞掉、掩盖了真正的数据处理失败让 bug 无声累积;裸 except 还会捕获所有异常包括 KeyboardInterrupt(Ctrl+C)和 SystemExit。这篇复盘从故障现场讲到吞异常的危害、异常处理原则,再到只捕获预期的具体异常、捕获后记录日志+统计错误数+按需报警、批处理跳过错误项要记录而非静默 pass、不知如何处理就别捕获让它往上抛的完整正解,以及可见性是解决问题的前提要坚定让错误暴露而非掩盖、假装没事比出事更可怕、要诚实直面并暴露问题而非掩耳盗铃维持表面太平的认知。

我在批处理循环里写了 try except pass,觉得"出错就跳过、别让程序崩"很稳健,结果一批数据悄悄少处理了一半、还谁都不知道,连 Ctrl+C 都按不停:一次裸 except 吞掉异常的深度复盘

那个"数据莫名其妙少了一半"是对账时才发现的:我有个批处理,循环处理一批数据。为了"健壮"——"别因为某条数据出错就让整个程序崩了"——我给循环体包了个 try: ... except: pass(出错就跳过,继续处理下一条)。我觉得这很稳。可线上跑完,对账发现处理结果悄悄少了一大半:本该处理 1 万条,实际只成功了几千条,另外几千条出错了、被 except: pass 静默吞掉、跳过了,而且没有任何日志、没有任何报警,谁都不知道;更离谱的是,我跑的时候想 Ctrl+C 中止,居然按不停。我盯着这个"稳健"的 try-except 复盘,才看明白,后背发凉:问题出在我用了"裸 except(或过宽的 except)+ pass"把异常全吞了第一,except: pass 把所有异常静默地吞掉了——出错的数据被默默跳过,既没记录、也没报警,于是"少处理了几千条"这件事无声无息地发生了,没人知道,等对账才暴露;第二,except:(不写异常类型)会捕获所有异常,包括 KeyboardInterrupt(Ctrl+C)和 SystemExit——所以我按 Ctrl+C 想停,那个中断信号也被 except: 吞了、pass 掉了,程序按不停。根本原因是:except: pass(或过宽的 except 后不处理)把异常静默吞掉,掩盖了真正的问题(数据处理失败),让 bug 无声无息;裸 except 还会吞掉本不该吞的 KeyboardInterrupt/SystemExit。问题的根,是用裸 except + pass 吞掉所有异常:既掩盖了数据处理失败(少处理还没人知道),又吞掉了 Ctrl+C 等不该吞的信号。这篇就把这次"裸 except 吞异常"的坑,从头到尾复盘一遍。

故障现场:try except pass,错误被静默吞掉

问题在于裸 except + pass 把所有异常静默吞掉、掩盖了真正的失败:

# ✗ 出问题的代码: 裸 except + pass, 出错就静默跳过
def process_all(items):
    success = 0
    for item in items:
        try:
            process(item)      # 处理一条数据
            success += 1
        except:                # ✗ 裸except: 捕获所有异常(包括KeyboardInterrupt/SystemExit)
            pass               # ✗ pass: 静默吞掉, 不记录、不报警, 啥也不做
    return success

# 现象:
# - 本该处理1万条, 实际只成功几千条; 另外几千条出错被静默跳过, 没有任何日志/报警 → 对账才发现;
# - 跑的时候按 Ctrl+C 想停, 居然停不下来(中断也被except吞了)。

# 为什么? "裸except + pass" 的两宗罪:
# 罪一: pass 静默吞掉异常 → 掩盖了真正的问题
#   - 数据处理失败(可能是数据脏、依赖挂了、代码bug), 本该被发现和处理;
#   - 可 except: pass 把它默默跳过, 没记录、没报警 → 失败"无声无息"地发生;
#   - → "少处理了几千条"这件大事, 没人知道, 直到对账才暴露(可能已造成损失)。
# 罪二: 裸except(except:不写类型)捕获【所有】异常, 包括不该捕获的:
#   - KeyboardInterrupt(Ctrl+C)、SystemExit(sys.exit) 也被它捕获;
#   - → Ctrl+C想停程序? 被except吞了、pass掉了 → 停不下来;
#   - 一些本该让程序立刻停下的严重错误, 也被它继续了 → 程序"带病硬撑"。

# 即使是 except Exception (不那么裸, 不抓KeyboardInterrupt), 后面 pass 也一样掩盖问题。

# 关键: except: pass(或过宽except后不处理)会静默吞掉异常、掩盖真正的失败(出错却无声无息),
#       裸except还会吞KeyboardInterrupt/SystemExit等不该吞的; 异常被吞=问题被藏, 后患无穷。

第一次想明白"原来那几千条是出错了被 pass 悄悄跳过的、还把 Ctrl+C 也吞了"时,我又懊恼又后怕:"我写 except: pass,本意是'容错、别崩',想着更稳健;完全没想到它把真正的错误全藏起来了,数据少处理了一大半都没人知道,连程序都关不掉。"这个坑最危险的地方在于:把"出错"变成了"静默"——错误明明发生了,却不报错、不留痕迹,你完全察觉不到,以为一切正常;问题悄悄累积(少处理、处理错),直到很晚才以"数据对不上"等更难查的形式暴露,甚至已造成实际损失;而它还披着"容错、稳健"的外衣,让人以为是好做法下面就来拆解,异常该怎么正确捕获和处理。

第一件事:搞懂"吞掉异常"的危害与异常处理原则

我顺着这次事故,把 Python 异常处理的原则彻底理清了。

为什么 except: pass(吞异常)危害极大? 异常该怎么处理?

【核心: 吞异常=把"出错"变"静默", 掩盖真正问题、让bug无声累积; 裸except还吞KeyboardInterrupt; 要捕获具体异常、处理/记录/重抛, 别裸except别pass】

1. 异常的作用: 它是"出了问题"的信号
   - 异常被抛出, 是程序在告诉你"这里出问题了, 需要处理/关注";
   - 正确的反应是: 处理它(恢复/重试/降级)、或记录它、或让它往上抛(让能处理的地方处理);
   - 而"吞掉它(except: pass)"= 捂住这个信号的嘴, 假装没出问题 → 问题还在, 只是你看不见了。

2. except: pass 的危害:
   - 掩盖真正的bug: 出错被静默跳过, 你以为正常, 实则数据少了/错了/逻辑没执行;
   - 无声累积: 失败不报警不留痕, 等很晚(对账/用户投诉)才暴露, 损失已造成、还难查;
   - "假装健壮": 看起来"不崩了", 实则是把问题藏起来了, 比崩了更糟(崩了你还知道出事了)。

3. 裸except (except: 不写类型) 额外的罪:
   - 捕获【所有】异常, 包括 KeyboardInterrupt(Ctrl+C)、SystemExit、以及本该暴露的严重错误;
   - → Ctrl+C停不下来、程序该退出时退不出、严重bug被掩盖继续硬撑;
   - 所以: 永远别用裸except; 至少用 except Exception(它不抓KeyboardInterrupt/SystemExit)。

4. 正确的异常处理原则:
   - ① 只捕获你"预期会发生、且知道怎么处理"的【具体异常】(except ValueError, except IOError...);
   - ② 捕获后要"做点什么": 处理/恢复/降级、或【记录日志】、或重新抛出; 别 pass(啥也不做);
   - ③ 不知道怎么处理的异常, 就【别捕获】, 让它往上抛(让上层或最终的处理者来管/让它崩并暴露);
   - ④ 别用裸except; 别捕获过宽(except Exception要慎用, 用了也要记录);
   - ⑤ "批处理跳过错误项"是合理需求, 但要【记录哪条错了、为什么】(而非静默pass), 并统计错误数。

5. 一句口诀: 异常要么处理、要么记录、要么抛出, 就是不能"静默吞掉"。

一句话: except: pass把异常静默吞掉=把出错变静默, 掩盖真正问题、让bug无声累积、损失已成才暴露; 裸except还吞
   Ctrl+C等; 要只捕获预期的具体异常并处理/记录/重抛, 别裸except别pass; 不知如何处理就别捕获、让它抛。

这套认知,是整个坑的根。异常的作用:它是"出了问题"的信号——正确反应是处理/记录/往上抛,而"吞掉它(except: pass)"=捂住信号的嘴、假装没出问题,问题还在只是你看不见except: pass 的危害:掩盖真正的 bug(以为正常实则数据少了/错了)、无声累积(很晚才暴露损失已成)、"假装健壮"(把问题藏起来比崩了更糟)。裸 except 额外的罪:捕获所有异常包括 KeyboardInterrupt(Ctrl+C)/SystemExit,Ctrl+C 停不下来、严重 bug 被掩盖硬撑;永远别用裸 except,至少用 except Exception正确原则:①只捕获预期的、知道怎么处理的具体异常 ②捕获后要处理/记录/重抛、别 pass ③不知如何处理就别捕获、让它往上抛 ④别裸 except、别过宽 ⑤批处理跳过错误项要记录哪条错了为什么并统计口诀:异常要么处理、要么记录、要么抛出,就是不能静默吞掉一句话:except: pass 把异常静默吞掉=把出错变静默,掩盖真正问题、让 bug 无声累积、损失已成才暴露;裸 except 还吞 Ctrl+C 等;要只捕获预期的具体异常并处理/记录/重抛,别裸 except 别 pass;不知如何处理就别捕获、让它抛。

第二件事:正解——捕获具体异常、记录、统计错误,别裸 except 别 pass

搞懂了原理,正解就清晰了:只捕获预期的具体异常、捕获后记录日志(哪条错了、为什么)、统计错误数;批处理跳过错误项要记录而非静默 pass;别用裸 except、别 except: pass

# ====== 正解: 捕获具体异常 + 记录 + 统计错误(批处理跳过但不静默) ======
import logging
logger = logging.getLogger(__name__)

def process_all(items):
    success, failed = 0, 0
    errors = []
    for item in items:
        try:
            process(item)
            success += 1
        except (ValueError, DataError) as e:    # ★ 只捕获预期的具体异常(不是裸except)
            failed += 1
            errors.append((item.id, str(e)))
            logger.error(f"处理失败 item={item.id}: {e}")   # ★ 记录! 哪条错了、为什么(不是pass)
            # 跳过这条继续, 但留下了痕迹
    # ★ 统计并暴露: 让"失败了多少"被看见、被报警
    if failed > 0:
        logger.warning(f"批处理完成: 成功{success}, 失败{failed}, 失败明细见日志")
        if failed > len(items) * 0.1:           # 失败率过高 → 报警/中止, 别假装没事
            alert(f"批处理失败率过高: {failed}/{len(items)}")
    return success, failed, errors
# → 出错的数据被记录、被统计、被报警 → "少处理了几千条"不再无声无息, 能被及时发现。
# ====== 几个原则示例 ======
# ✗ 永远别这样:
# try: ... except: pass            # 裸except + pass: 吞所有(含Ctrl+C)、静默
# try: ... except Exception: pass  # 过宽 + pass: 静默吞掉, 掩盖问题

# ✓ 只捕获预期的具体异常, 并处理/记录:
try:
    data = json.loads(text)
except json.JSONDecodeError as e:    # 预期会发生(外部数据可能不合法)、知道怎么处理
    logger.warning(f"JSON解析失败: {e}")
    data = default_data              # 降级到默认值

# ✓ 不知道怎么处理的, 别捕获, 让它往上抛(让能处理的地方处理, 或让它崩并暴露):
result = risky_operation()           # 不catch, 出了意外异常就让它抛, 别假装能处理

# ✓ 实在要兜底所有异常(如服务最外层), 至少: except Exception(不抓Ctrl+C) + 记录 + 重抛或返回明确错误
try:
    handle_request()
except Exception as e:
    logger.exception("请求处理异常")   # 记录完整堆栈
    return error_response(e)          # 返回明确的错误响应, 而非静默吞掉

# 核心: 只捕获预期的具体异常并处理/记录/重抛; 批处理跳过错误项要记录+统计+按需报警, 别静默pass;
#   别用裸except(会吞Ctrl+C); 不知如何处理的异常就别捕获、让它抛——异常绝不能被静默吞掉。

修复的核心,是"捕获具体异常、记录、统计,别裸 except 别 pass"正解:捕获具体异常+记录+统计错误——except (ValueError, DataError)、捕获后 logger.error 记录哪条错了为什么、统计成功/失败数、失败率过高就报警/中止;出错的数据被记录被统计被报警,不再无声无息几个原则:永远别 except: pass/except Exception: pass;只捕获预期的具体异常并处理/记录(如 JSONDecodeError 降级);不知怎么处理的别捕获让它往上抛;要兜底所有也至少 except Exception(不抓 Ctrl+C)+记录+重抛/返回明确错误归根结底:只捕获预期的具体异常并处理/记录/重抛;批处理跳过错误项要记录+统计+按需报警,别静默 pass;别用裸 except(会吞 Ctrl+C);不知如何处理的异常就别捕获、让它抛——异常绝不能被静默吞掉。

第三件事:异常处理中其他常见的坑

排查后我把异常处理相关的其他坑也系统梳理了一遍。

异常处理的其他常见坑

# 1. except: pass 吞异常(本文): 掩盖问题、无声累积。→ 捕获具体异常+记录, 别pass。

# 2. 裸except捕获KeyboardInterrupt/SystemExit: Ctrl+C停不下来。→ 用except Exception或具体类型。

# 3. 捕获过宽(except Exception)且不细分: 把预期外的bug也当业务异常处理了。→ 捕获具体异常。

# 4. catch后丢失原始异常信息: 重新抛新异常没带上原因(raise ... from e)。→ 保留异常链。

# 5. 在finally里return/raise: 会覆盖try里的return/异常(吞掉原异常)。→ 别在finally里return/raise。

# 6. 异常当流程控制: 用try-except做正常逻辑分支(性能差、可读性差)。→ 异常只用于异常情况。

# 7. 只记日志不处理也不抛: 记了日志但程序继续用错误的状态走下去。→ 记录后还要决定怎么办。

# 8. 吞掉异常返回默认值掩盖问题(同561/553思路): 该报错的地方静默给默认值。→ 区分"能降级"和"该报错"。

# 共同根源: 异常是"出问题"的信号和信息载体; 异常处理的本质是"如何对待这个出问题的信号"——
#   是认真应对(处理/记录/抛出), 还是捂住它假装没事(吞掉)? 而"吞掉异常"几乎总是错的——
#   它用"看起来没出错"的假象, 掩盖了"实际出错了"的真相, 让问题潜伏、累积、在更糟的时刻爆发。

# 核心: 把异常当成"必须认真对待的出错信号"——捕获具体的、处理或记录或抛出、保留异常链、别静默吞掉;
#   让错误"可见"(报错/日志/报警), 而非"隐形"; 一个会"如实报错"的系统, 远比一个"默默吞错"的系统可靠。

排查让我把异常处理的其他坑也梳理清了。一、except: pass 吞异常(本文)。二、裸 except 捕获 KeyboardInterrupt三、捕获过宽不细分四、catch 后丢失原始异常信息五、finally 里 return/raise 吞原异常六、异常当流程控制七、只记日志不处理也不抛八、吞异常返回默认值掩盖问题它们的共同根源是:异常是"出问题"的信号和信息载体;异常处理的本质是"如何对待这个出问题的信号"——是认真应对(处理/记录/抛出),还是捂住它假装没事(吞掉)?而"吞掉异常"几乎总是错的——它用"看起来没出错"的假象,掩盖了"实际出错了"的真相,让问题潜伏、累积、在更糟的时刻爆发核心是:把异常当成"必须认真对待的出错信号"——捕获具体的、处理或记录或抛出、保留异常链、别静默吞掉;让错误"可见"(报错/日志/报警),而非"隐形";一个会"如实报错"的系统,远比一个"默默吞错"的系统可靠下面这张图,是这次裸 except 坑的成因与解法:

第四件事:对待异常的几种方式对比表

这次踩坑后,我把对待异常的几种方式对比成一张表。

方式 错误可见吗 问题被解决/暴露吗 评价
except: pass(吞掉) ✗ 完全不可见 ✗ 被掩盖、潜伏 最差, 别用
捕获+记录日志 ✓ 日志里可见 暴露(可事后查) 合理
捕获+处理/降级 (可记录) ✓ 被妥善应对 好(对预期异常)
不捕获, 让它往上抛 ✓ 抛出/崩溃可见 ✓ 暴露给能处理的 好(对意外异常)

这张表把几种方式钉清了。核心是:对待异常的方式,本质是在回答"要不要让'出错了'这件事被知道"——except: pass 选择了"不让任何人知道"(隐藏);其他方式都选择了"让出错以某种形式被知道"(记录/抛出/处理时感知);而"让错误被知道",几乎总是对的——因为你只能解决"你知道的问题",对"被隐藏的问题"你束手无策(甚至不知道它存在)它给我的最大启发是:"可见性(visibility)"是处理任何"问题/错误/异常状况"的第一前提——问题只有先"被看见",才谈得上被诊断、被解决;隐藏问题(吞异常、静默失败、报喜不报忧)等于放弃了解决它的机会;"让错误大声地、如实地暴露出来",虽然短期"不好看"(报错、崩溃),却是长期可靠的基础这给了我一种构建系统的根本价值观:设计系统(以及做事)时,要坚定地站在"让问题可见"这一边——用报错、日志、监控、告警让错误和异常状况"浮出水面、被人知道",而非用各种方式(吞异常、静默降级、掩盖)把它们藏起来;"宁可让错误吵闹地暴露, 也别让它安静地潜伏";"把'让问题可见'当成第一原则、坚决反对掩盖错误",是构建可观测、可诊断、可信赖系统的根本价值观认清可见性是解决问题的前提、坚定让错误暴露而非掩盖——是这个坑带给我的认知。

第五件事:这次事故暴露的"假装没事"比"出事"更可怕

这次让我反思更深一层:except: pass 追求的"不崩、看起来稳",恰恰是最危险的。我把"大声出错"和"静默假装没事"对比成表。

维度 大声出错(抛/崩/报警) 静默假装没事(吞掉)
当下表现 难看(报错/崩) 好看(没崩、跑完了)
问题 立刻被发现 被隐藏、潜伏
损失 小(及时止损) 大(无声累积、晚发现)
可诊断 容易(有错误信息) 难(无痕迹)
本质 诚实、可控 掩耳盗铃、失控

这张表道出了最深的教训。核心是:except: pass 给了我一种"程序没崩、跑完了、看起来一切正常"的表面的安稳;可这份"安稳"是掩耳盗铃——它不是"真的没问题",而是"把问题藏起来、假装没问题";而"假装没事"的代价, 是问题在暗处无声地累积、失控, 等到瞒不住时已是大窟窿;"静默地带病运行"远比"大声地报错崩溃"危险它给我的深刻启发是:面对错误/问题,"掩盖它、维持表面正常"和"暴露它、哪怕难看",是两种根本对立的态度——前者贪图当下的"好看/不添乱",把代价推给未来;后者直面当下的"难看",换来问题的及时解决和长期的可靠;"报喜不报忧、掩盖问题维持表面光鲜", 无论在系统里还是组织里, 都是滋生大灾难的温床——因为被掩盖的小问题, 会在无人知晓中长成压垮一切的大问题这给了我一种价值取向上的坚定:无论是写代码还是做事,都要选择"诚实地暴露问题"而非"掩盖问题维持表面正常"——哪怕暴露问题当下"难看"(报错、被批评、显得不完美), 也远胜于把问题藏起来、让它在暗处酿成大祸;"直面并暴露问题、拒绝掩耳盗铃式的'假装没事'",是一种至关重要的工程诚实(和处世智慧)——会吞错的代码和会掩盖问题的人, 都不可靠认清假装没事比出事更可怕、要诚实暴露问题而非掩盖维持表面正常——是这个 except: pass 坑带给我的工程态度。

第六件事:写 try-except 时,我现在的自检习惯

现在每当我要写一个 try-except,我都会先按这张图问自己:

这张图的精髓,是"捕获具体异常、要么处理要么记录、别裸 except 别 pass、不知如何处理就让它抛"知道怎么处理具体异常+处理、只想跳过记录+统计别 pass、意外异常别捕获让它抛、裸 except改成 except Exception、pass至少记日志这套习惯,让我从"try except pass 图省事"变成了"捕获具体异常、让错误可见"——核心始终是:只捕获预期的具体异常并处理/记录/重抛,别用裸 except、别 except: pass,不知如何处理的异常就别捕获、让它往上抛,异常绝不能静默吞掉。

我立下的几条规矩

这场"裸 except 吞异常、数据悄悄少了一半"的事故,换来了我写 Python 异常处理时,刻进骨子里的几条铁律:

  1. 异常是"出问题"的信号,吞掉它(except: pass)= 捂住信号、假装没事。
  2. except: pass 掩盖真正的 bug、让失败无声累积,比崩了更糟(崩了你还知道)。
  3. 裸 except(不写类型)会捕获 KeyboardInterrupt/SystemExit,Ctrl+C 都停不下来。
  4. 只捕获预期的、知道怎么处理的具体异常,别捕获过宽。
  5. 捕获后要做点什么:处理/降级、或记录日志、或重新抛出,别 pass。
  6. 批处理跳过错误项要记录哪条错了为什么 + 统计错误数 + 按需报警。
  7. 不知道怎么处理的异常,别捕获,让它往上抛——让错误可见,而非隐形。

写在最后

回头看,这场由"一个图省事的 except: pass"引发的、数据悄悄少了一半的事故,真正教给我的,远不止"捕获具体异常、记录日志"这一个技巧。它让我对"面对'出了问题'这件事, '把它捂住、假装没发生' 是最坏的应对——因为它换来的'表面太平', 是用'问题在暗处失控生长'为代价的",有了一次刻骨的体会。我栽跟头,是因为我对"出错"有一种"别让它显出来、别添乱"的逃避心态——我写 except: pass 时,潜意识里想的是"万一出错了, 别崩、别报错、悄悄跳过就好, 看起来太太平平的";我追求的是那个"没出错的假象、太平的表面";可我换来的"太平",是建立在"把真实的出错全藏起来"之上的——那几千条处理失败的数据,就在我这份"假装的太平"里被悄悄丢弃、无人知晓、酿成了对账时才发现的大窟窿;我以为我在"容错", 其实我在"纵容错误潜伏"这让我领悟到一个关于"直面问题"的深刻认知:对待问题/错误,最危险的态度是"掩盖、回避、假装没发生"——因为问题不会因为你不看它就消失,它只会在你看不见的地方继续生长、累积,直到大到瞒不住、酿成更大的灾难;"解决问题"的第一步, 永远是"承认并直面问题";而"掩盖问题", 是在为更大的问题埋单;"报喜不报忧"式的处理, 是对可靠性的背叛这给了我一种面对问题的根本态度:无论是写代码、还是做事,遇到错误和问题时,要选择"直面它、暴露它、解决它",而非"捂住它、回避它、假装它没发生"——哪怕直面当下会带来报错、崩溃、麻烦、难堪, 也远胜于把问题藏进暗处、任其失控;"诚实地直面并暴露问题, 而非掩盖以求表面太平",是一种贯穿工程与处世的根本品格——它让问题在还小、还可控、损失还有限时, 就被解决认清掩盖问题是最坏的应对、要诚实直面暴露而非假装太平——这,是我用一次裸 except 吞异常的事故,换来的、关于异常处理、也关于如何对待一切问题的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次手指要敲下 except: pass 时停一下、改成捕获具体异常并记录,那我对着那悄悄少了一半的数据复盘的这段时间,就值了。

—— 别看了 · 2026
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理 邮箱1846861578@qq.com。
技术教程

我把带对话记忆的 Agent 做成了单例,上线后用户 A 问的问题,Agent 拿着用户 B 的对话历史在回答,记忆全串了:一次 Agent 会话状态没隔离的深度复盘

2026-6-2 23:09:27

技术教程

我用 new Date 造了个 6 月 1 日,它却给我变成了 7 月 1 日;后端传来的日期前端显示又差了一天:一次 JavaScript Date 月份从 0 开始与解析时区的深度复盘

2026-6-2 23:22:05

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索