模块名与内置模块重名会导致python优先加载本地文件而非标准库，引发attributeerror等错误；最稳妥做法是立即重命名，如json.py→data_json.py，避免依赖as别名或相对导入等无效方案。
模块名和内置模块重名会直接导致导入失败
Python解释器在导入时，会按 sys.path 顺序搜索模块，当前目录（'' 或 .）永远排第一。一旦你写了 json.py、os.py 或 math.py，后续任何 import json 都会加载你的本地文件，而不是标准库——这会导致 AttributeError、ImportError，甚至 RecursionError（比如你重写了 os 却又在它里面调用了 os.path）。
最稳妥的做法是：**立刻重命名**。不要尝试“绕过”或“临时屏蔽路径”，那只是把问题拖到更难调试的阶段。
-
json.py→ 改成data_json.py或json_utils.py -
os.py→ 改成file_system.py或path_helper.py - 包名同理：
math/目录必须改，哪怕它里面只有__init__.py
from . import xxx 无法解决与内置模块的冲突
相对导入只对包内有效，且前提是当前模块本身已被识别为包的一部分（即通过 python -m package.module 启动，或其父目录在 sys.path 中）。如果你的 main.py 直接运行，而旁边有个 requests.py，那么 from . import requests 依然会失败——Python 不会因为加了点号就跳过当前目录优先级。
真正起作用的是导入方式本身：
- ❌
import requests→ 加载本地requests.py - ✅
import requests as _requests→ 仍错，别名不改变查找顺序 - ✅
from urllib.request import urlopen→ 绕开冲突，用标准库其他模块达成目标 - ✅
import sys; sys.path.pop(0); import requests; sys.path.insert(0, '')→ 可行但危险，影响全局路径，多线程下不可靠
as 别名只能缓解函数/类冲突，不能解决模块级覆盖
as 是命名空间层面的操作，它发生在导入成功之后。如果 import pandas 已经因为本地 pandas.py 失败了，import pandas as pd 同样报错。
但它对以下场景有效：
- 两个不同模块提供同名函数：
from html import escape as html_escape和from xml.sax.saxutils import escape as xml_escape - 避免覆盖内置名：
from collections import defaultdict as dd（防止不小心写defaultdict = {}覆盖掉类型） - 长模块名缩写：
import torch.nn.functional as F，这是惯例，不是补救措施
注意：as 不改变模块对象本身，pd.__name__ 还是 'pandas'，只是绑定到新变量名。
__all__ 和相对导入对命名冲突基本无效
__all__ 控制的是 from module import * 的导出范围，不影响模块是否被找到；相对导入（from .utils import helper）依赖包结构完整性和执行方式，它不参与“模块名是否与内置冲突”的判定逻辑。
真正能隔离命名空间的，只有层级结构：
- 把所有自定义代码放进顶层包，如
myproject/ - 确保每个子目录都有
__init__.py（哪怕为空） - 用绝对导入：
from myproject.utils import config，而非import config
这种结构下，即使你有 myproject/json.py，也不会干扰 import json，因为 Python 查找 json 时不会钻进 myproject/ 里——除非你手动把它加进了 sys.path 前端。
最容易被忽略的一点：IDE（如 PyCharm、VS Code）的代码补全和静态检查，往往基于当前工作目录推断模块路径，它们可能“提前”报错或给出错误提示，但这不代表运行时一定出错；反之，有时运行正常，但 IDE 标红一堆——得看 sys.path 实际顺序，而不是编辑器猜测。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
