Linux文件系统严格区分大小写而Windows不区分，导致import、open、模板加载等操作在Linux下因大小写不一致报FileNotFoundError或Class not found；需用ls -l或find确认真实文件名，统一命名规范并清理缓存。
FileNotFoundError但文件明明存在？先确认大小写是否一致
Linux 文件系统严格区分大小写，Windows 不区分——这是所有问题的根源。比如 config.py 和 Config.py 在 Windows 上 import 都能成功，在 Linux 上只有后者能被 import config 加载（前提是文件名是 Config.py）。报错时不要急着改代码逻辑，先用 ls -l 或 find . -iname "config.py" 看真实文件名，再比对 import 语句和文件系统中的大小写是否完全一致。
import 报错 Class not found？检查模块路径与文件名是否镜像匹配
Python 的模块导入机制依赖文件系统路径与模块名的严格映射。常见错误包括：
-
from app.models.user import User要求路径为app/models/user.py，且内部必须是class User:；若文件是app/models/User.py（大写 U），Linux 下直接失败 - 包内
__init__.py中的from .user import User，若该目录下实际是User.py，而你写了from .User import User，也会因模块名不匹配报错 - 使用
sys.path.append()手动加路径时，路径字符串里混入了大小写错误（如"./APP/utils"），Linux 下os.listdir()返回的子目录名是小写的app，导致后续导入链断裂
模板/配置/数据文件加载失败？别只盯路径拼接，先看文件系统本身
很多脚本用 open("conf/settings.yaml") 或 jinja2.Environment(loader=FileSystemLoader("templates")) 加载资源，看似跟 import 无关，但同样受大小写影响：
-
open("DATA/input.csv")在 Linux 上找不到data/input.csv，即使两个文件内容一样——因为它们是不同文件 - Jinja2 的
FileSystemLoader传入"Templates"，但磁盘上是templates/目录，loader 内部调用os.path.isdir()返回False，静默失败或抛出TemplateNotFound - 使用
pathlib.Path("Config").exists()判断配置目录是否存在，但实际目录名为config，结果为False，后续逻辑跳过，没有报错却行为异常
如何一次性发现所有大小写不一致隐患？用 find + grep 快速扫描
在项目根目录执行以下命令，能快速揪出命名不规范的 Python 文件和引用：
立即学习“Python免费学习笔记（深入）”；
find . -name "*.py" -not -name "__*.py" | xargs grep -l "import.*[a-z][A-Z]\|from.*[a-z][A-Z]"
再配合：
find . -path "./app/*" -name "*.py" | grep -E "/[a-z]+\.py$|/[a-z][a-z0-9]*[A-Z]"
这两条命令分别找出：含驼峰式 import 的文件、以及文件名本身就不符合 PascalCase/PureLowercase 规范的源码。修复顺序建议是：先统一文件名大小写 → 再修正 import 语句 → 最后清理缓存（rm -rf __pycache__/ 和 find . -name "*.pyc" -delete）。
最容易被忽略的是：大小写问题往往不报 ImportError，而是表现为后续变量未定义、属性不存在、或空配置静默生效——它藏在运行时逻辑深处，而不是 import 那一行。排查时别只盯着报错栈顶，要顺藤摸到最底层的文件系统访问点。
