错误由import路径大小写不一致引起，node.js（esm）和typescript严格区分大小写，即使windows系统容忍，vscode、tsc及运行时仍按linux/macos规则校验，需确保导入路径与实际文件名（含大小写）完全一致。
import路径大小写不一致导致编译报错
Node.js（尤其是ESM模式）和TypeScript在解析import语句时，严格区分文件名大小写。Windows系统本身对路径不敏感，但VSCode底层的TypeScript语言服务、tsc编译器、以及运行时（如node --experimental-specifier-resolution=node未启用时）都按Linux/macOS规则校验——import { foo } from './Utils.js' 和实际文件 utils.js 会直接触发 Cannot find module 或 TS2307 错误。
- 先确认报错是否真由大小写引起：在终端执行
ls -la src/（macOS/Linux）或dir src\（Windows PowerShell），肉眼比对 import 路径与磁盘文件名的大小写是否完全一致 - VSCode编辑器内右键“在资源管理器中显示”该导入文件，看实际文件名——常有
ApiService.ts被误写成apiservice.ts或APIservice.ts - TypeScript项目需检查
tsconfig.json中是否含"forceConsistentCasingInFileNames": true（默认开启），它会让TS编译器主动拦截大小写不匹配，而非等到运行时报错
npm install后模块名标红但实际能运行？
VSCode里 import axios from 'axios' 下划波浪线，但 node index.js 正常运行，大概率是类型定义没对上，不是大小写问题。但若标红的是你本地写的模块（如 import { helper } from '@/utils/Helper'），且 Helper.ts 实际名为 helper.ts，那这就是典型大小写陷阱。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 检查
jsconfig.json或tsconfig.json的"baseUrl"和"paths"配置——别让路径别名掩盖真实文件名差异，例如"@/utils/*": ["src/utils/*"]后，仍要确保src/utils/Helper.ts文件名拼写与import中一致 - 禁用 VSCode 的文件缓存干扰：关闭所有打开的TS/JS文件 → 删除项目根目录下
.vscode文件夹（不影响配置，只删工作区缓存）→ 重启 VSCode - 避免靠重命名文件“碰运气”：用 VSCode 的“重构 → 重命名符号”（F2）改文件名，它会自动同步所有 import 语句；手动改名后务必全局搜索旧名残留
Windows下开发却要兼容Linux部署？必须提前验证
你在Windows上开发时，import './Config.js' 指向 config.js 可能不报错（系统容忍），但CI流水线或Docker容器里立刻失败。这不是VSCode的问题，而是环境差异暴露的代码缺陷。
- 在VSCode集成终端中，用
git status看是否有文件名仅大小写不同的“重命名”变更（Git在Windows默认不区分大小写，需设git config core.ignorecase false才能捕获） - CI阶段加一行检查：在
.github/workflows/ci.yml或 Jenkinsfile 中插入find . -name "*.js" -o -name "*.ts" | grep -i "config\|utils" | grep -v -i "config"类似命令，强制发现混用 - VSCode设置里开启
"files.autoSave": "onFocusChange"+ 安装插件Case-Preserving File Rename，它会在你重命名时警告大小写冲突风险
最易被忽略的是：TypeScript的 import 解析和 Node.js 的 require() 加载走两套逻辑，前者由TS服务控制，后者由Node运行时控制。即使TS不报错，运行时仍可能炸——所以不能只信VSCode的波浪线，必须在目标环境（如WSL或Docker）里跑一次 node --check index.js 验证路径真实性。
