要让 Modern Fortran 扩展正常工作，必须确保 gfortran 和 python3 都在系统的 PATH 环境变量里，并且 fortls 需要手动通过 pip 安装并显式配置路径，否则语法高亮、跳转定义等功能会失效。调试时，必须使用包含 -g 标志的编译命令，并正确配置 launch.json 来调用 GDB。
代码没高亮、fortls 启动失败、Ctrl+Click 跳不到模块定义——如果你遇到了这些问题，先别急着怀疑扩展本身。很多时候，问题并非出在环境没配好，而是关键依赖链在 Python 或系统路径上断掉了。
确认 gfortran 和 python3 都在系统 PATH 里
VSCode 的 Fortran 插件并非独立运行，它更像一个“调度中心”，需要外部工具协同工作：gfortran 负责底层的语法检查和编译，而 python3 则是运行语言服务器 fortls 的引擎。两者缺一不可，且必须能被 VSCode 直接找到。
- 最直接的验证方法是打开终端，分别执行
gfortran --version和python3 --version。如果两者都能顺利输出版本号，说明基础环境是通的；只要有一个失败，插件就很可能卡在“Language Server Starting…”的提示上。 - Windows 用户需要特别注意：即便在终端里能用，也不代表 VSCode 能识别。使用 MinGW-w64 安装后，务必手动将
gfortran.exe所在的目录（例如C:\mingw64\bin）添加到系统环境变量PATH中。否则，从 GUI 启动的 VSCode 进程可能无法继承正确的路径。 - macOS 用户如果通过 Homebrew 或 pyenv 管理了多个 Python 版本，需要确保终端里
python3命令指向的是你打算用来安装fortls的那个版本。系统自带的/usr/bin/python3通常不包含 pip，容易导致后续安装失败。
fortls 必须用 pip install fortls 安装，不能只靠扩展自动安装
Modern Fortran 扩展虽然提供了“自动安装 fortls”的选项，但在许多系统环境下（尤其是 Linux/macOS 的非 root 用户，或是 Windows 的 WSL 环境），这个过程可能会静默失败，且不给出任何明确的错误提示。
- 因此，最稳妥的做法是主动出击：在终端手动执行
pip install fortls。如果遇到权限问题，可以加上--user标志：pip install --user fortls。 - 安装后，务必验证一下：执行
fortls --version，应该能看到类似fortls 2.4.1的输出。如果提示 “command not found”，那说明 pip 安装的可执行文件路径没有被加入到系统的PATH中。在 Linux/macOS 上，通常需要检查~/.local/bin；在 Windows 上，则需要查看%APPDATA%\Python\Python3x\Scripts这样的目录。 - 为了万无一失，可以在 VSCode 的设置中显式指定
fortls的完整路径。例如，在settings.json中添加："fortran.fortls.path": "/home/you/.local/bin/fortls"（Linux/macOS）或"fortran.fortls.path": "C:\\Users\\You\\AppData\\Roaming\\Python\\Python311\\Scripts\\fortls.exe"（Windows）。
调试前先配好 launch.json，别指望 Code Runner 编译带调试信息
很多用户习惯用 Code Runner 插件来快速编译运行，但这里有个陷阱：它的默认编译命令是 gfortran -o $fileNameWithoutExt $fileName，其中不包含生成调试信息的 -g 标志。结果就是，虽然程序能跑，但当你试图用 GDB 调试时，会发现看不到变量名和源码行，断点也形同虚设。
- 要进行真正的源码级调试，需要在项目根目录的
.vscode文件夹下创建launch.json文件。虽然 Fortran 没有专用的调试器类型，但可以借用 C/C++ 的配置，使用cppdbg类型来调用 GDB：
{
"version": "0.2.0",
"configurations": [
{
"name": "Fortran Debug",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/build/main",
"miDebuggerPath": "gdb",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"setupCommands": [
{ "description": "Enable pretty-printing", "text": "-enable-pretty-printing", "ignoreFailures": true }
],
"preLaunchTask": "build"
}
]
}
tasks.json 中，确保编译命令包含了 -g -O0 等调试优化选项：{
"version": "2.0.0",
"tasks": [
{
"label": "build",
"type": "shell",
"command": "gfortran",
"args": [
"-g", "-O0", "-Wall", "-fcheck=all",
"-c", "${file}",
"-o", "${fileDirname}/build/${fileBasenameNoExtension}.o"
],
"group": "build",
"problemMatcher": ["$gcc"]
}
]
}
Code Runner 适合快速测试单文件脚本。但一旦涉及多模块调用、数组越界检查或数值精度追踪等复杂场景，切换到这套正式的调试流程是必须的。多模块项目里，include 和 use 的路径容易被忽略
在包含多个源文件的 Fortran 项目中，fortls 默认只扫描当前打开的文件及其同级目录。所以，当你在代码中写下 use my_module 却看到 “cannot find module” 的错误时，先别急着检查拼写，很可能只是模块文件不在插件的搜索路径里。
- 解决方法是在
.vscode/settings.json中显式声明模块的搜索路径。例如："fortran.fortls.includePaths": ["${workspaceFolder}/src/modules", "${workspaceFolder}/lib"]。 - 另外，要区分 Fortran 的
include 'file.inc'和 C 语言的#include。前者是简单的文本替换，其路径是相对于包含它的源文件所在目录，而不是工作区的根目录，这一点常常被混淆。 - 还有一个细节：模块文件（通常是
.f90）必须已经被编译过（或者至少被fortls解析过），use语句才能实现跳转。如果你刚新建了一个my_module.f90文件，还没来得及保存或触发语言服务器解析，那么在其他文件中写use my_module时，它可能会显示为灰色且无法跳转。
说到底，Fortran 开发环境的脆弱点往往不在编译器本身，而在于 Python 环境、系统 PATH 和工作区路径这三者之间隐晦的耦合关系。任何一个环节的路径出现偏差，都可能导致“功能看似开启，实则半残”的状态。因此，动手配置前，先花两分钟敲命令验证基础链路，远比事后花半小时去查日志要高效得多。
