Sublime Text 3配置C#环境与Unity脚本开发-sublime-PHP中文网

sublime text 3 可写 unity c# 脚本，但需正确配置 omnisharp：匹配 unity 版本的 mono/.net 运行时、精确指向 managed 目录下的 unityengine.dll 等程序集、确保 unity 生成并更新 .csproj 文件，并为 source.cs 作用域单独设置语法感知补全与 build system。

sublime text 3配置c#环境与unity脚本开发

Sublime Text 3 能写 Unity C# 脚本，但不是装个插件就完事——OmniSharp 必须加载对的 Unity DLL、用对的 Mono/.NET 运行时，且 .csproj 文件必须由 Unity 正确生成并保持更新，缺一不可。

OmniSharp 启动失败或不补全？先确认 Mono 和 Unity DLL 路径

Sublime 的 OmniSharp 插件依赖 Mono（Windows/macOS/Linux）或 .NET SDK（仅 macOS/Linux 新版）运行，但它真正理解 Unity 代码，靠的是读取 Unity 安装目录下的核心程序集，比如 UnityEngine.dll、UnityEditor.dll。路径配错，补全、跳转、错误提示全失效。

Windows 用户：Mono 不是必须项，但 OmniSharp 默认走 Mono；若用 .NET SDK，请在 OmniSharp.sublime-settings 中显式设置 "omnisharp_server_path" 指向你本地 omnisharp/OmniSharp.exe 或通过 "use_global_mono" 设为 "auto" 让它自动探测
macOS/Linux 用户：必须安装匹配的 .NET SDK（非 runtime），版本需与 Unity 的 Scripting Runtime Version 一致；查法：Unity 编辑器 → Edit → Project Settings → Player → Other Settings
Unity DLL 路径必须精确到文件夹层级：~/Unity/Hub/Editor/[version]/Editor/Data/Managed/（macOS）或 C:Program FilesUnityHubEditor[version]EditorDataManaged（Windows）；不能只填到 Data，也不能漏掉 Managed
如果看到 Could not load file or assembly 'UnityEngine' 类错误，八成是 DLL 路径没指向 Managed 目录，或者该目录下压根没有 UnityEngine.dll（旧版 Unity 可能在 Managed/UnityEngine 子目录里，需手动调整）

Ctrl+Click 跳转无效？检查 .csproj 是否由 Unity 生成且未被破坏

Sublime 本身不解析项目结构，OmniSharp 全靠 Unity 输出的 .csproj 文件知道“哪些脚本属于这个项目”“引用了哪些程序集”。双击脚本打开 Sublime 是无效的，必须让 Unity 主动导出工程定义。

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

在 Unity 编辑器中，必须执行 Assets → Open C# Project（不是双击脚本！不是右键 Open with…！），这会强制 Unity 重写所有 .csproj 和 .sln 文件
确认 Unity Preferences → External Tools → External Script Editor 已设为 Sublime Text，并勾选 Generate all .csproj files；否则 Unity 可能只生成主模块，漏掉 UnityEditor 或 UnityEngine.UI
常见陷阱：项目根目录下存在残留的 obj/、bin/ 或损坏的 .csproj；建议关闭 Unity 和 Sublime，删掉这些目录和文件，再重启 Unity 并重执行 Open C# Project
生成后检查 YourProject.csproj 内容：应包含类似 <reference include="UnityEngine"><hintpath>...</hintpath></reference> 的条目，且 HintPath 指向你配置的 Unity DLL 路径

注释快捷键失效或自动补全不触发？改 Syntax Specific 设置而非全局

Sublime 的 C# 补全行为高度依赖语法作用域（scope）。全局设置容易被其他插件覆盖或误匹配，必须针对 source.cs 作用域单独配置。

菜单操作路径：Preferences → Settings – More → Syntax Specific – User，确保当前文件是 .cs 后缀，才会弹出 C# 专属设置面板
必须粘贴以下最小有效配置（不是覆盖全部，只补关键项）：

{
  "auto_complete": true,
  "auto_complete_selector": "source.cs - comment",
  "auto_complete_triggers": [
    {"selector": "source.cs", "characters": "."}
  ],
  "word_separators": "./\()"'-:,.;~!@#$%^&*|+=[]{}`~?"
}

重点："auto_complete_selector" 必须是 "source.cs - comment"，写成 "source - comment" 会同时影响 Python/JS，导致注释区也弹出补全框
"word_separators" 里保留点号 .，否则输入 transform. 时不会触发成员补全

Build System 编译报错“csc not found”？别硬套 VS 批处理，优先用 dotnet run

Unity 脚本不能直接编译成独立可执行文件，所谓“编译”只是做语法检查。用 csc.exe 或 mcs 去编译单个 .cs 文件必然失败——缺少引用、无入口点、路径混乱。日常开发只需验证语法，dotnet run 更轻量可靠。

新建 Build System：Tools → Build System → New Build System
内容填入（适配 macOS/Linux，Windows 用户把 shell_cmd 改为 cmd /c dotnet run）：

{
  "shell_cmd": "dotnet build -nologo -clp:ErrorsOnly",
  "file_regex": "^(.*?):([0-9]+):([0-9]+): (error|warning) ([A-Z]+[0-9]+): (.*)$",
  "selector": "source.cs",
  "working_dir": "$project_path"
}

关键点：working_dir 必须设为 $project_path，否则 dotnet build 找不到 .csproj；不要用 $file_path，Unity 项目不是单文件工程
这个 Build System 不运行代码，只做快速语法/引用检查，比启动完整 IDE 快 5–8 秒；真要运行测试逻辑，还是回 Unity 编辑器点 Play
如果提示 dotnet: command not found，说明没加进 PATH，macOS/Linux 用户可在终端运行 echo 'export PATH="$PATH:/usr/local/share/dotnet"' >> ~/.zshrc 并重开 Sublime

最易被忽略的一点：Unity 每次升级编辑器版本，Managed 目录路径和 DLL 名称可能微调，Scripting Runtime Version 也会变——这意味着你之前配好的 OmniSharp 设置、.NET SDK 版本、甚至 Build System 都得同步复查，不是一劳永逸的事。