Python ArgumentParser传参InfluxDBClient，打印正确但连接用默认值的问题

你遇到的问题核心是：实际发起InfluxDB写入请求的客户端实例，根本不是你传入正确命令行参数初始化的那个实例。结合你的代码结构，两个诱因是最高发的：

• 跨模块导入的执行顺序错位
  你把参数解析逻辑写在argument_onstream.py里，通过from argument_onstream import args导入使用。只要你的代码里有更早触发InfluxDBClient初始化的逻辑——比如同目录的公共工具模块、第三方封装代码在模块顶层就直接初始化了InfluxDBClient，而且初始化的时候用的是类自带的默认值host=localhost, port=8086——哪怕你后面打印的args值完全正确，这个提前跑起来的默认客户端已经在后台尝试发请求了，就会造成“打印参数全对、但连接还是打默认地址”的错觉。
  举个典型的错误场景：

  # utils/influx_helper.py
  from influxdb import InfluxDBClient
  # 模块加载时就直接初始化，根本没读外部传入的参数
  default_client = InfluxDBClient(database='TEST') # 这里host、port全用了默认的localhost:8086
  
  # test.py
  from argument_onstream import args
  from utils.influx_helper import default_client
  # 这里打印的args确实是正确的命令行传入值，但后面发请求用的是提前初始化的default_client，根本没用到你传的IP
  print(args.grafana_ip, args.grafana_port)
  default_client.write_points(...)
  

• 参数解析的作用域错位
  如果你写argument_onstream.py的时候，把parse_known_args()的逻辑放在了if __name__ == "__main__":的代码块里，那当你从test.py导入这个模块的时候，参数解析的代码根本不会执行。这种情况一般会直接报AttributeError，但如果你的模块顶层提前定义了一个带默认值的Namespace对象，导入的时候拿到的就是全是默认值的对象——哪怕你后续在test.py里额外执行了一次参数解析，打印的时候看到的是正确的IP，但实际传给InfluxDBClient的还是那个提前导入的、带默认值的旧args对象，就会触发连接报错。

• 不要只打印args的值，直接打印InfluxDBClient实例的实际连接配置：

  client = InfluxDBClient(host=args.grafana_ip, port=args.grafana_port, database='TEST')
  # 直接读实例内部的连接参数，确认实际值
  print("客户端实际连接地址：", client._host, client._port)
  

  如果打印出来是localhost 8086，说明你传给InfluxDBClient的args对象本身就是带默认值的，不是命令行传入的正确值——大概率是导入时机太早，参数解析还没执行，你拿到的是模块加载时的默认对象。
• 删掉所有模块顶层的InfluxDBClient初始化逻辑，统一在args解析完成、命令行参数拿到正确值之后，再创建客户端实例。不要把数据库连接放在模块加载阶段提前初始化。
• 检查项目里是否存在重复定义的args变量、重复初始化的InfluxDBClient实例：多文件嵌套导入的时候很容易导错对象，你打印的是当前文件里的args，但创建客户端的时候用的是别的模块里提前初始化的旧实例。

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