Linux文件系统大小写敏感且不限扩展名，文件名总长限255字节（含中文），路径长限4095字节；点开头文件默认隐藏，斜杠禁止出现在文件名中；跨平台开发需统一小写命名并加入CI检查。
Linux 文件系统本身不强制依赖扩展名，也不限制扩展名长度，但文件名整体受255字节限制；大小写敏感是默认行为，源于底层文件系统（如 ext4、XFS）对字符的逐字节精确比对，不是系统“设置”出来的特性，而是设计使然。
文件名与扩展名的实际限制
Linux 中没有单独针对“扩展名”的限制规则。所谓扩展名（如 .log、.config.json）只是文件名中带点的后缀部分，它和前面的主名称一起计入总长度。关键约束有两条：
- 单个文件名最多 255 字节（注意是字节，不是字符；含中文时一个汉字占 3 字节，容易超限）
- 完整路径（从 / 开始算起）最长 4095 字节
- 点（.）本身无特殊权限，但以 . 开头的文件默认为隐藏文件（如 .bashrc），不被 ls 默认列出
- 斜杠（/）不能出现在文件名中——它是路径分隔符，出现即报错
大小写敏感的本质与影响
这不是 Linux “故意较真”，而是文件系统在 inode 层面对文件名做原始字节存储和比对的结果。比如创建 ReadMe.md 后，系统实际存的是 ASCII 或 UTF-8 编码的字节序列 0x52 0x65 0x61 0x64 0x4d 0x65 0x2e 0x6d 0x64。后续访问时，只要传入的路径字节序列不完全一致（哪怕只差一个大写 R → r），就查不到该文件。
- 同一目录下可共存 config.yaml、Config.yaml、CONFIG.YAML —— 它们是三个独立文件
- Git 不会自动检测纯大小写变更的重命名（如 file.txt → FILE.TXT），可能造成 Windows 开发、Linux 部署时丢失引用
- 容器镜像构建中若 COPY 的源文件名大小写与目标环境不一致，docker build 会静默失败或找不到文件
跨平台开发中的典型风险点
开发者常在 Windows 写代码（文件系统不区分大小写），测试通过后推到 Linux 运行，结果崩溃。常见场景包括：
- 配置文件加载：代码写 File.Open("appsettings.json")，但实际部署时文件名为 AppSettings.json
- Web 路由或静态资源：Nginx/Apache 按字面匹配 URI 路径，/images/Logo.png 和 /images/logo.png 返回不同内容甚至 404
- 数据库迁移脚本：MySQL 在 Linux 上表名大小写敏感（lower_case_table_names=0），user 与 User 是两张表
应对策略与实用建议
无法改变文件系统行为，但可以控制代码和流程来规避问题：
- 统一约定：团队内强制小写+短横线命名（user-profile-service.yaml），禁用驼峰和混合大小写
- CI/CD 中加入检查：用 find . -name "*[A-Z]*" | grep -v "node_modules\|venv" 扫描非法命名
- C# / Java / Python 等语言需手动实现大小写不敏感查找：枚举目录 + StringComparer.OrdinalIgnoreCase 比对文件名（勿用 .ToLower() 处理路径）
- 挂载 FAT32 或 exFAT 分区时，Linux 会继承其大小写不敏感特性，但不推荐用于主力开发盘——行为不一致反而更难调试
