from module import * 会静默覆盖同名标识符，包括内置函数、自定义变量及其它模块导入项，导致运行时错误且难以调试；ide 和静态检查工具失效，依赖分析与重构困难，__all__ 无法防止覆盖，打包和 ci 检查易漏判，最危险的是逻辑错误却无报错。
它不是“省事”，而是把命名空间交出去，由导入顺序决定谁活下来——你写的函数、变量、甚至 len 或 open 都可能被静默覆盖，且毫无提示。
from module import * 会无条件覆盖同名标识符
Python 按执行顺序处理导入，后出现的 from module import * 会直接替换当前作用域中所有同名符号，包括你自己定义的、内置的、其他模块导入的。
-
from requests import *后再写def get(): ...，你的get函数立刻失效，后续调用全走 requests 的get()，参数不匹配就报TypeError -
from datetime import *会把datetime类注入命名空间；若你之前有datetime = "2025-01-01"，这个字符串变量当场被覆盖，变成一个类对象 - 连
open、len、sum这些内置函数都可能被第三方模块里同名函数替换，错误发生在运行时，且 traceback 不会提示“你被 import * 覆盖了”
IDE 和静态检查工具在 import * 前基本失能
PyCharm、VS Code（Pylance）、mypy、pylint 全部依赖显式导入路径做符号解析。一旦用了 from module import *，它们就失去判断依据。
- Ctrl+Click 跳转到定义 → 跳到哪？可能是任意一个导出该名的模块，甚至跳进标准库或 C 扩展源码
-
mypy对json.loads("...")只能推断为Any，彻底丢失返回类型是dict还是list的信息 - 重命名一个函数？全局搜
def parse不够，还得搜所有from .* import \*，否则漏掉某处脚本偷偷覆盖了它 -
git blame查不到某行log(...)是来自logging、math还是自定义utils，重构时不敢动
__all__ 不能兜底，且掩盖真实依赖
有人觉得“我模块里写了 __all__ = ['foo', 'Bar'] 就安全了”，其实不然。
- 没声明
__all__的模块（比如很多老代码、os、shutil），import *会导入所有非下划线开头的名称，包括调试用的临时函数、未文档化的内部工具 - 即使有
__all__，它只控制“导出什么”，不控制“谁会被覆盖”——两个都声明了__all__的模块仍会发生覆盖冲突 - 打包工具（如
PyInstaller）和依赖扫描器（如pipdeptree、CI 中的 import 检查）无法从from utils import *推断出实际用了utils.load_config还是utils.parse_csv，容易漏打包或误报警
最危险的不是报错，而是不报错：变量被覆盖后程序照常运行，但逻辑已错，直到上线后某个边缘 case 触发才暴露——而那时你根本想不到问题出在几行看似无害的 import * 上。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
