from module import * 会无条件覆盖当前作用域中同名标识符，导致函数、变量甚至内置函数被替换，引发难以排查的运行时错误，且破坏ide支持、静态检查、依赖分析与团队协作。
from module import * 会直接覆盖当前作用域里的同名标识符
这不是“可能冲突”，而是确定会发生。Python 按导入顺序执行，后导入的同名符号无条件覆盖先定义的——包括你自己的函数、变量，甚至内置函数。
常见错误现象：open 变成不可用、len 报 TypeError: 'int' object is not callable、自己写的 parse() 突然行为异常，但查不到调用来源。
- 如果你写了
def get(): return "mine"，又执行from requests import *，那后续所有get()都会调用 requests 的get()，参数不匹配直接报错 -
from datetime import *会把datetime类注入命名空间，若你之前有datetime = "2025-01-01"，这个字符串就被覆盖了 - 连
__all__都不能完全兜底：没声明__all__的模块，import *会导入所有非下划线开头的名称，包括你本想隐藏的调试函数
IDE 和静态检查工具对 from module import * 完全失能
PyCharm、VS Code（Pylance）、mypy 这些工具依赖明确的导入路径做符号解析。一旦用了 from module import *，它们就无法判断某个函数到底来自哪，补全失效、跳转失效、未使用警告失效、类型推导退化为 Any。
- mypy 对
from requests import *后的get("https://a.b")只能标注为def get(...) -> Any，彻底丢失Response类型信息 - Git blame 查不到某行
json.loads()是从json还是ujson或自定义模块来的，重构时不敢动 - 重命名一个函数？先全局搜
from.*import \*，否则可能漏掉某个脚本里偷偷导入了它
团队协作中它让依赖关系彻底隐形
显式导入是代码的“接口文档”。import pandas as pd 或 from pathlib import Path 一眼就知道项目依赖什么；而 from utils import * 让人完全无法判断这个 load_config() 是封装过的，还是直接抄了第三方库的逻辑。
- 新人看代码第一反应不是“这函数干啥”，而是“这函数在哪定义的？”——然后卡住
- CI 流程里做依赖分析（比如检测是否误引入 dev-only 模块）时，
import *会让扫描器漏掉真实依赖 - 打包工具（如 PyInstaller）可能漏掉未显式引用的模块，导致运行时报
ModuleNotFoundError
替代方案不是“更麻烦”，而是更可控
不用 import * 不等于要写十行导入。关键是按需、显式、可追溯：
- 只导入真正用到的项：
from math import sqrt, pi，比import math少打字，又不污染命名空间 - 用
as缩短高频模块名：import numpy as np、from typing import List, Optional as Opt - 模块内通过
__all__主动收口：__all__ = ["Client", "connect"]，既约束星号导入范围，也相当于 API 声明 - 小脚本临时用？可以，但别提交进 Git —— 提交前务必改成显式导入，否则下次你或别人维护时，就是 debug 黑洞
实际项目里最常被忽略的一点：命名空间污染不是立刻崩，而是缓慢腐化。它让 bug 出现在看似无关的修改之后，让排查时间从 5 分钟拉长到半天。越早建立显式导入习惯，后期省下的调试时间就越真实。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
