WSL 中无法直接运行 Windows 版 MATLAB，因其为 PE 格式，Linux 内核不支持；推荐方案是 Windows 端启动 VSCode，通过 Remote-WSL 扩展使用 WSL 后端，MATLAB 插件调用宿主机原生 matlab.exe。
不能直接调用——WSL 的 matlab 命令默认找不到 Windows 宿主机上的 MATLAB，因为 WSL 不自动继承 Windows 的 PATH，且 MATLAB for Windows 二进制（matlab.exe）在 Linux 环境下根本无法运行。
为什么 /mnt/c/Program Files/MATLAB/... 下的 matlab.exe 在 WSL 里执行会报错
WSL 是 Linux 内核兼容层，不是模拟器。matlab.exe 是 Windows PE 格式可执行文件，Linux 内核无法加载它。即使你用 cmd.exe /c "C:...matlab.exe" 尝试桥接，也会因 GUI 依赖、许可证验证失败、路径空格转义等问题静默退出或卡死。
- 执行
/mnt/c/Program Files/MATLAB/R2025b/bin/matlab.exe→ 报错：cannot execute binary file: Exec format error - 用
wine强行跑？MATLAB 不支持 Wine，启动即崩溃，且无官方兼容性保证 - 通过
cmd.exe /c启动 → MATLAB 桌面可能闪现后关闭，-batch模式常因工作目录、环境变量缺失而报Undefined function or variable
可行方案：只在 Windows 端启动 VSCode，复用 WSL 后端 + 调用宿主机 MATLAB
这是唯一稳定、无需额外代理或脚本的路径。核心逻辑是：VSCode 前端在 Windows 上打开 Windows 路径，后端语言服务和终端走 WSL，而 MATLAB 执行仍由 Windows 原生进程完成 —— 三者不混在同一上下文里。
- 确保已安装 Remote - WSL 扩展，并从 Windows 文件资源管理器中右键项目文件夹 → “Open with Code”（不是在 WSL 终端里输
code .） - VSCode 底部状态栏显示
WSL: Ubuntu（或你发行版名），说明后端已切换成功，但当前工作区路径仍是C:path oproject - 此时 MATLAB 插件（
mathworks.matlab）能正常读取 Windows 下的matlab.defaultInterpreterPath，比如："matlab.defaultInterpreterPath": "C:\Program Files\MATLAB\R2025b\bin\matlab.exe" - 运行脚本时，插件底层调用的是 Windows PowerShell 或 CMD，而非 WSL bash，所以 MATLAB 启动、路径解析、许可证校验全部走原生链路
如果坚持要在 WSL 终端里触发 MATLAB，只能靠 Windows 工具链中转
这不是推荐做法，仅作技术兜底。适用于极少数必须从 bash 脚本驱动 MATLAB 的场景（如 CI 流水线封装），但会牺牲调试、补全、实时交互能力。
- 在 WSL 中安装
windows-terminal或确保cmd.exe可被调用（通常默认可用） - 手动测试通路：
cmd.exe /c 'start "" "C:Program FilesMATLABR2025binmatlab.exe" -batch "run("C:\tmp\test.m"); exit;"' - 注意：
start是异步的，无法捕获 stdout；若需结果，改用cmd.exe /c同步阻塞调用，但要处理好路径斜杠（Windows 风格）和引号嵌套 - VSCode 的
tasks.json或 Pythonsubprocess调用时，必须显式指定 shell 为cmd.exe，且所有路径用反斜杠+双引号包裹，$fileDirname这类 VSCode 变量需先转换为 Windows 格式
真正容易被忽略的点是：VSCode 的 MATLAB 插件和 WSL 扩展之间没有“跨系统执行”的设计契约。它们各自守界 —— MATLAB 插件管 Windows 进程调度，WSL 扩展管 Linux 工具链。强行越界，就得自己填所有坑：路径映射、环境变量透传、信号转发、编码同步。不如让 VSCode 在 Windows 上开窗，把 WSL 当后台编译器用，MATLAB 当后台计算器用，各司其职最稳。
