面对大型遗留代码库的重构难题，我完全理解你不想贸然注释代码的顾虑——毕竟生产环境的稳定性是第一位的。下面分享几个实用的、低风险的方法来确认生产环境中代码的实际执行情况：

1. 无侵入式埋点统计调用情况 #

可以给可疑的函数/代码块添加轻量的调用记录逻辑，且通过环境变量控制是否开启，避免影响正常业务：

• 写一个简单的装饰器，比如：

  import os
  import logging
  from functools import wraps
  
  def track_production_calls(func):
      @wraps(func)
      def wrapper(*args, **kwargs):
          # 仅在生产环境开启追踪
          if os.getenv('PROD_TRACK_ENABLED') == 'true':
              logging.info(f"[PROD_TRACK] 函数 {func.__module__}.{func.__name__} 被调用")
          return func(*args, **kwargs)
      return wrapper
  

• 给可疑函数加上这个装饰器，然后在生产环境的部分实例中开启PROD_TRACK_ENABLED=true，观察日志中是否有对应的调用记录。
• 注意：高并发场景下建议添加采样率控制（比如每100次调用只记录1次），避免日志量过大影响性能；同时绝对不要记录用户敏感数据。

2. 利用现有监控/日志系统回溯 #

先从已有的数据入手，不用额外改代码：

• 检查应用日志：搜索可疑代码相关的关键词（比如函数名、模块名、专属日志语句），看是否有调用痕迹。如果用了ELK、Splunk这类日志分析工具，可以设置时间范围（比如覆盖一个完整业务周期）进行全量检索。
• 借助APM工具：如果你的服务接入了应用性能监控工具，可以直接查看调用链路追踪，确认是否有请求走到这些可疑代码分支。
• 查看错误日志：如果这些代码被调用但出现过异常，错误日志里大概率会留下相关堆栈信息。

3. 灰度发布+渐进式验证 #

如果上述方法无法完全确认，可以用灰度的方式逐步验证：

• 先在极小比例的生产流量中，给可疑代码添加“调用告警”——当代码被执行时，发送一条低优先级的告警到你的监控系统（比如Prometheus告警、企业微信通知）。
• 持续观察1-2个业务周期（比如一周、一个月），如果没有收到告警，再扩大灰度范围到所有实例，继续验证。
• 更谨慎的方式：暂时保留原有代码逻辑，但在函数开头添加调用记录，同时将函数的返回值/副作用做“无害处理”（比如如果是写入操作，改成模拟写入但不实际执行），观察是否有业务异常。如果没有异常，说明这段代码的逻辑可能确实不再被依赖。

4. 静态分析辅助排查（仅作参考） #

用静态代码分析工具辅助找出潜在的未被调用代码，但要注意动态调用的局限性：

• 使用pycscope、pylint等工具分析代码依赖，找出没有被任何模块直接引用的函数。
• 注意：这种方法无法检测动态调用（比如getattr(obj, func_name)、eval、字符串拼接调用），所以只能作为补充，不能作为最终判断依据。

关键注意事项 #

• 覆盖完整业务周期：有些代码可能只在特定时间触发（比如月度报表、节日活动），所以监控时间一定要足够长。
• 兼顾所有部署实例：确保你的监控覆盖了生产环境的所有服务器/容器实例，避免遗漏某个实例上的调用。
• 优先保证稳定性：任何埋点或灰度操作都要以不影响生产业务为前提，一旦发现异常立即回滚。

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