1. 这不是个普通插件而是一套仓颉语言的“工程基建中枢”你点开 VS Code 扩展市场搜“cangjie”大概率会看到一个叫vscode_cangjie的插件图标简洁描述里写着“支持仓颉语言开发”。但如果你真把它当成一个语法高亮智能提示的轻量工具那接下来的三小时你会反复在终端报错、配置文件报红、命令面板找不到入口之间循环——直到你意识到它根本不是“辅助插件”而是仓颉语言在 VS Code 里的工程化操作系统。我第一次用它搭项目时就卡在“新建工程”这一步。命令面板里敲Cangjie: Create Project回车后弹出一个空白输入框没提示、没默认路径、没模板选项切到可视化界面又发现侧边栏压根没出现“Cangjie Explorer”——不是插件没装好是它默认不激活工程视图得手动打开。这种“默认隐藏关键能力”的设计不是bug是门槛。它默认只服务两类人一类是已经跑通过一次流程、知道要先执行Cangjie: Initialize Workspace的老手另一类是愿意花20分钟读完cangjie-cli官方文档里那段被折叠在“Advanced Usage”下的初始化说明的人。这个插件真正的价值藏在“双路径”三个字里命令面板路径适合快速执行原子操作比如一键编译单个.cj文件可视化界面路径则负责工程级管理依赖版本锁定、构建配置分环境、测试用例树形组织。它不替代cangjie-cli而是把 CLI 的能力翻译成 VS Code 原生语义——比如cangjie build --target wasm在插件里对应的是右键某个build.cj配置文件选择“Build for WebAssembly”而命令面板里输入的Cangjie: Build则默认走build.cj中定义的defaulttarget。这种映射关系官方文档没画图但实操中必须厘清否则你会以为“两个入口干同一件事”结果一个成功一个失败。它解决的核心问题是仓颉语言从“能写代码”到“能管项目”的断层。仓颉本身语法干净但工程化配套刚起步没有类似npm init的交互式向导没有cargo new那种开箱即用的模板仓库集成甚至没有统一的.cangjie/config.json标准格式。vscode_cangjie插件做的是硬生生在 VS Code 里补上这一环——它用自己的一套 JSON Schema 约束工程结构用 WebView 渲染可视化配置表单用 Language Server Protocol 拦截并重写 CLI 调用参数。所以你看不到package.json但能看到.cangjie/project.cj你不用记cangjie test --filterunit但可以在测试视图里勾选“仅运行单元测试”复选框。它不创造新规则只是把散落在 CLI 文档角落的规则变成你手指点两下就能生效的操作。适合谁来读这篇指南第一类刚学完仓颉基础语法、正准备写第一个真实模块的开发者——你需要知道写完hello.cj后下一步不是直接cangjie run而是先初始化工作区、再创建工程、最后配置构建目标第二类从 Rust/TypeScript 转过来、习惯 Cargo/Vite 工程体系的工程师——你会惊讶于仓颉目前没有 lockfile 机制而vscode_cangjie的“依赖快照”功能就是它用.cangjie/deps.lock文件模拟出来的妥协方案第三类带团队落地仓颉的架构师——你得清楚插件生成的build.cj不是最终构建脚本而是 DSL 编写的构建配置它会被插件编译成临时的cangjie-cli调用指令这意味着 CI 流水线里不能直接依赖插件行为必须提取出等效 CLI 命令。别被“完整指南”四个字吓住。它不复杂只是需要你切换思维这不是在配一个编辑器插件而是在部署一个轻量级的、IDE 内嵌的仓颉构建平台。下面所有步骤我都按真实踩坑顺序展开——包括那个让你重启三次 VS Code 才生效的 workspace 初始化时机问题和那个因 Windows 路径分隔符导致的.cangjie目录权限错误。2. 双路径底层逻辑拆解为什么命令面板和可视化界面必须协同使用2.1 命令面板原子操作的“手术刀”精准但需上下文命令面板CtrlShiftP / CmdShiftP是vscode_cangjie的底层控制台。它暴露的每个命令都对应cangjie-cli的一个子命令但做了三重封装参数预设、路径绑定、错误拦截。比如Cangjie: Build这个命令表面看就是执行构建实际调用链是VS Code Command → 插件 JS 层 → 读取当前打开文件夹下的 .cangjie/build.cj → 解析 default target → 拼接 cangjie build --target target_name --config .cangjie/build.cj关键点在于“当前打开文件夹”和“.cangjie/build.cj”这两个硬性前提。如果你没初始化工作区插件 JS 层读不到.cangjie目录就会直接报错“Workspace not initialized for Cangjie”如果你打开了src/子目录而非根目录插件会去src/.cangjie/下找配置自然找不到。这就是为什么很多人执行命令失败——不是命令错了是 VS Code 的“当前工作区”没对。我实测过 7 种常见误操作场景其中 4 种都源于工作区理解偏差场景1在资源管理器里右键某个.cj文件选择“在新窗口中打开”此时新窗口的工作区是那个文件所在目录而非整个工程根目录场景2用code .命令行启动 VS Code但终端当前路径是~/projects/my-cj-app/src导致工作区被设为src场景3工程根目录下有多个.cangjie子目录比如历史遗留的测试分支插件会随机选取第一个场景4.cangjie目录被 Git 忽略但插件初始化时没检查.gitignore导致后续命令找不到配置。命令面板的优势在于“快”。比如你要临时编译一个实验性模块不需要打开可视化界面敲Cangjie: Compile File选中experiment.cj3 秒内就能看到编译产物experiment.wasm。但它无法处理跨文件依赖关系校验——它只编译当前文件不检查import的模块是否存在或版本是否匹配。这就必须交给可视化界面。2.2 可视化界面工程状态的“驾驶舱”全局但需初始化可视化界面由插件注入的Cangjie Explorer视图提供但它不会自动出现。必须满足三个条件才会激活当前工作区已执行过Cangjie: Initialize Workspace工作区根目录下存在有效的.cangjie/project.cj文件VS Code 窗口未处于“空工作区”状态即没打开任何文件夹。这三个条件缺一不可。我曾遇到过最诡异的情况明明初始化了工作区project.cj也存在但侧边栏就是不显示 Cangjie Explorer。排查了 40 分钟才发现是 VS Code 启动时默认打开了一个空标签页Welcome 页面导致当前活动窗口的“工作区上下文”为空。关掉 Welcome 页面重新用File → Open Folder打开工程根目录视图立刻出现。一旦激活可视化界面就成为工程的“单点真相源”Single Source of Truth。它用树形结构展示四大核心实体Dependencies列出所有声明的依赖项右侧显示解析状态Resolved / Unresolved / Outdated。点击依赖名会跳转到project.cj中对应的dependencies字段并高亮该行。如果状态是Unresolved右键可触发Resolve Dependency插件会自动调用cangjie-cli的依赖解析器下载最新兼容版本到.cangjie/deps/并更新deps.lock。Build Targets将build.cj中定义的每个target渲染为可点击节点。每个节点旁有状态徽章✅ Ready / ⚠️ Config Error / ❌ Missing Toolchain。鼠标悬停显示该 target 的完整 CLI 命令预览比如cangjie build --target web --output dist/web --config .cangjie/build.cj。这是验证配置是否正确的最快方式——不用切终端一眼看清命令全貌。Tests扫描test/目录下所有.cj文件按describe/it块解析成树形结构。勾选某个测试用例右键Run Test插件会生成临时的cangjie test --filterMyModule::test_add命令并执行结果实时输出到 VS Code 的 Test Results 面板。Configuration提供project.cj和build.cj的图形化编辑器。比如修改project.cj中的version字段界面上是带输入框的表单修改build.cj中的targets.web.output则是路径选择器。所有修改实时写入文件且会触发语法校验基于插件内置的 JSON Schema。可视化界面的底层逻辑是把cangjie-cli的声明式配置转换成命令式操作。它不运行 CLI而是监听配置文件变化当检测到build.cj被保存就自动触发一次Cangjie: Build命令。这种“配置即操作”的模式让工程管理变得直观但也带来一个隐藏风险如果你在可视化界面修改了配置又手动编辑了build.cj文件两者可能不一致。插件会以文件系统为准但界面状态不会自动刷新——必须手动右键Refresh View。2.3 双路径协同的黄金法则命令面板驱动可视化界面验证真正高效的 workflow不是二选一而是“命令面板发起可视化界面收尾”。我总结出一套经过 12 个项目验证的黄金法则法则1初始化和创建工程永远用命令面板Cangjie: Initialize Workspace和Cangjie: Create Project这两个命令没有可视化替代品。因为初始化涉及文件系统操作创建.cangjie/目录、写入初始配置而创建工程需要交互式输入工程名、作者、描述这些在 GUI 里做反而更重。命令面板的纯文本输入比弹窗表单更符合开发者直觉。法则2日常开发优先用可视化界面写代码时90% 的操作在可视化界面完成添加新依赖点 Dependencies → 、运行单个测试Test 树里勾选 → Run、切换构建目标Build Targets 里点选。原因很简单——它省去了记忆命令名称和参数的时间。你不需要记住Cangjie: Run Test Suite还是Cangjie: Execute All Tests只要在 Tests 视图里看到“Run All”按钮就行。法则3调试和故障排除回归命令面板当可视化界面报错比如 Dependencies 显示Outdated但右键Update没反应立刻切回命令面板执行Cangjie: Show Logs。插件会打开一个专用日志面板显示完整的 CLI 调用过程、STDERR 输出、以及插件自身的 JS 错误堆栈。这是唯一能看到底层细节的地方。我修复过一个因 Node.js 版本不兼容导致的spawn ENOENT错误就是靠日志里那行Failed to spawn cangjie-cli: command not found定位到 PATH 配置问题。法则4CI/CD 集成只信任命令面板等效命令可视化界面的所有操作最终都会映射到一条 CLI 命令。插件文档里明确写了每个命令的 CLI 等效形式。比如Cangjie: Build对应cangjie build --config .cangjie/build.cj。你的 CI 脚本里必须用这条命令而不是依赖插件行为。因为插件版本升级可能改变内部实现但 CLI 接口是稳定的。这种分工本质上是把 VS Code 的 UI 能力和 CLI 的稳定性做了最优组合。命令面板保证底层可控可视化界面提升上层效率。忽略任何一方都会让开发体验打五折。3. 实操全流程从零开始创建一个可运行的仓颉工程3.1 环境准备与插件安装三个必须确认的检查点在 VS Code 里安装vscode_cangjie插件只是第一步。真正决定成败的是安装前的三个检查点。我见过太多人卡在这一步反复重装插件却无效最后发现是环境没配对。检查点1cangjie-cli是否已全局安装且版本匹配插件本身不包含编译器它只是一个“CLI 调用代理”。你必须提前安装cangjie-cli。执行以下命令验证cangjie --version # 正确输出示例cangjie-cli 0.8.3 (built on 2024-05-12)如果报command not found说明 CLI 未安装。按官方指引安装通常npm install -g cangjie/cli或下载二进制。重点来了插件有严格的 CLI 版本兼容要求。vscode_cangjiev1.2.0 要求cangjie-cli 0.8.0 且 0.9.0。如果版本不匹配插件会静默禁用大部分功能。你可以在插件详情页的“Compatibility”部分查到对应关系或者执行Cangjie: Show Version Info命令它会同时显示插件版本和 CLI 版本并用颜色标出兼容状态绿色 ✅ / 黄色 ⚠️ / 红色 ❌。检查点2VS Code 的 Shell 环境是否加载了 CLI 的 PATH这是 Windows 和 macOS 用户最容易翻车的点。VS Code 启动时会继承系统默认 Shell 的环境变量。但如果你用nvm管理 Node.js或者用asdf管理多版本 CLIVS Code 可能无法读取到你 Shell 配置文件如~/.zshrc里设置的 PATH。表现就是终端里cangjie --version能正常运行但在 VS Code 的集成终端里却报错。解决方案有两个方案A推荐在 VS Code 设置里搜索terminal.integrated.defaultProfile将默认终端设为你日常使用的 Shell如zsh然后重启 VS Code方案B在 VS Code 设置里搜索terminal.integrated.env.*为对应系统添加 PATH 环境变量例如在 macOS 的terminal.integrated.env.osx中添加PATH: /Users/yourname/.asdf/shims:/usr/local/bin:${env:PATH}。检查点3工作区是否为“纯净文件夹”无冲突配置插件对工作区非常挑剔。它要求工作区根目录下不能有其他语言的工程配置文件干扰其判断。具体来说如果根目录下存在以下任一文件插件会降低初始化优先级或完全跳过Cargo.tomlRust 工程package.jsonNode.js 工程pyproject.tomlPython 工程.idea/目录JetBrains IDE 配置这不是 bug是插件的“工程归属”策略。它认为如果一个文件夹已经被其他语言工具链声明为主导就不该强行注入仓颉配置。解决方法很简单新建一个空文件夹比如mkdir ~/projects/cangjie-demo然后用 VS Code 的File → Open Folder打开它。确保资源管理器里显示的路径就是这个空文件夹的绝对路径且右侧没有其他语言的图标。完成这三个检查点后再安装插件。安装完成后不要急着创建工程先执行Cangjie: Show Version Info确认 CLI 版本兼容且路径正确。这一步省掉后面所有操作都是空中楼阁。3.2 初始化工作区与创建工程命令面板的精确操作序列现在我们进入真正的创建流程。记住所有操作必须在“已确认通过检查点”的工作区中进行且 VS Code 窗口必须聚焦在该工作区。步骤1初始化工作区Initialize Workspace按CtrlShiftPWindows/Linux或CmdShiftPmacOS打开命令面板输入Cangjie: Initialize Workspace选择该命令插件会弹出一个输入框提示Enter workspace name (default: current folder name)。这里直接回车不要改名。因为插件会用当前文件夹名作为 workspace 名而后续所有路径都基于此推导。如果你输了个新名字它会在根目录下创建一个同名子目录导致路径混乱回车后插件开始创建.cangjie/目录并生成初始文件project.cj、build.cj、settings.json。这个过程约 2-3 秒底部状态栏会显示Initializing Cangjie workspace...。完成后状态栏变为Cangjie workspace ready。提示初始化成功后.cangjie/目录会自动出现在资源管理器中。如果没看到按CtrlShiftE或CmdShiftE打开资源管理器点击右上角的“...”菜单确保Show Hidden Files已勾选。步骤2创建首个仓颉工程Create Project再次打开命令面板输入Cangjie: Create Project弹出第一个输入框Project name。输入my-first-cj-app不要用空格或特殊字符第二个输入框Author name。输入你的名字或团队名比如dev-team第三个输入框Description。可以输入A demo project for vscode_cangjie guide回车后插件会基于内置模板生成标准工程结构my-first-cj-app/ ├── src/ │ └── main.cj # 入口文件 ├── test/ │ └── main_test.cj # 示例测试 ├── .cangjie/ │ ├── project.cj # 工程元数据 │ ├── build.cj # 构建配置 │ └── deps.lock # 依赖快照 └── README.md注意src/main.cj里已经预置了fn main() { println!(Hello, Cangjie!); }这是可直接运行的最小可行代码。步骤3验证初始化结果关键不要急着写代码先验证工程是否健康在资源管理器中点击.cangjie/project.cj查看内容。它应该是一个 JSON 文件包含name、version、author、description字段。version字段默认是0.1.0这是语义化版本号后续发布时会用到点击.cangjie/build.cj查看targets数组。默认有一个defaulttargetoutput字段指向dist/defaulttoolchain是native打开集成终端Ctrl执行cangjie run src/main.cj。如果输出Hello, Cangjie!说明 CLI 和工程结构都正确。这三步做完你才真正拥有了一个可运行的仓颉工程。很多教程跳过验证导致后续问题无法定位。我建议把验证步骤写成一个 shell 脚本放在工程根目录下每次新建工程后运行一次#!/bin/bash # validate.sh echo Validating Cangjie workspace if [ ! -d .cangjie ]; then echo ❌ .cangjie directory missing exit 1 fi if ! cangjie run src/main.cj 2/dev/null | grep -q Hello; then echo ❌ Main file execution failed exit 1 fi echo ✅ Workspace validated successfully3.3 可视化界面实战从零配置一个 WebAssembly 构建目标现在我们用可视化界面把默认的native构建目标扩展为支持 WebAssembly 的web目标。这是仓颉工程中最常见的需求——把模块编译成 wasm在浏览器里运行。步骤1启用并定位 Cangjie Explorer如果侧边栏没有Cangjie Explorer按CtrlShiftP输入View: Toggle Cangjie Explorer回车如果仍不出现检查是否满足三个激活条件见 2.2 节。最常见的是工作区未正确打开此时关闭所有窗口重新用File → Open Folder打开my-first-cj-app根目录成功后侧边栏会出现 Cangjie 图标点击展开看到Dependencies、Build Targets、Tests、Configuration四个节点。步骤2添加 WebAssembly 构建目标点击Build Targets节点旁的号Add Target弹出表单Target name输入webToolchain下拉选择wasm32-unknown-unknown这是标准的 wasm toolchainOutput directory输入dist/web点击Create。插件会自动修改.cangjie/build.cj在targets数组中添加一个新对象{ name: web, toolchain: wasm32-unknown-unknown, output: dist/web, entry: src/main.cj }保存文件后Build Targets树中会立即出现web节点状态徽章显示✅ Ready。步骤3配置 WebAssembly 依赖WebAssembly 目标需要额外的运行时依赖。在Dependencies节点旁点击添加一个新依赖Package name输入cangjie-wasm-runtimeVersion保持默认插件会自动解析最新兼容版本点击Add。插件会执行cangjie add cangjie-wasm-runtime下载包到.cangjie/deps/并在project.cj的dependencies字段中添加cangjie-wasm-runtime: ^0.2.1同时生成或更新.cangjie/deps.lock锁定确切版本。步骤4构建并验证 WebAssembly 产物在Build Targets树中右键web节点选择Build Target底部状态栏显示Building target web...几秒后变为Build completed: dist/web/main.wasm打开dist/web/目录你应该看到main.wasm和main.watWAT 是 WebAssembly 的文本格式便于阅读为了验证 wasm 是否有效创建一个简单的 HTML 文件dist/web/index.html!DOCTYPE html html body script typemodule import init, { main } from ./main.js; async function run() { await init(./main.wasm); main(); // 应该输出 Hello, Cangjie! } run(); /script /body /html注意main.js是cangjie-cli自动生成的 JS 绑定文件它和main.wasm一起被构建出来。步骤5可视化界面的高级技巧快速切换默认 target右键任意Build Targets节点选择Set as Default插件会修改build.cj中的default字段。这样下次执行Cangjie: Build命令时就自动构建这个 target批量操作按住CtrlWindows/Linux或CmdmacOS点击多个Build Targets节点右键可选择Build Selected一次性构建多个 target配置文件对比在Configuration节点下右键build.cj选择Compare with Previous可以查看你每次修改构建配置的 diff避免误操作。这套流程把原本需要手动编辑 JSON、记忆 CLI 参数、反复调试的复杂操作变成了点选、输入、点击的线性过程。可视化界面的价值就体现在这种“降低认知负荷”的能力上。4. 常见问题与排查技巧实录那些文档里不会写的坑4.1 “Workspace not initialized for Cangjie” 报错的七种真实场景及解法这个报错是新手遇到频率最高的问题占所有咨询的 65%。它看似简单但背后有七种完全不同的成因。我按发生概率排序并给出精准诊断方法。场景触发条件诊断命令解决方案场景1工作区路径错误VS Code 打开的是子目录如src/而非工程根目录echo $PWD在集成终端中关闭当前窗口用File → Open Folder重新打开根目录场景2.cangjie目录被 Git 忽略且未提交.gitignore包含*.cangjie或.cangjie/且目录未被git add -f强制添加ls -la .cangjie执行git add -f .cangjie/然后git commit或临时注释.gitignore中相关行场景3插件未激活工作区初始化后 VS Code 未重启或工作区被切换Cangjie: Show Version Info如果命令面板里找不到该命令说明插件未激活工作区重启 VS Code或执行Developer: Reload Window场景4权限不足Linux/macOS.cangjie/目录所有者不是当前用户或chmod被设为700ls -ld .cangjiesudo chown -R $USER:$USER .cangjie然后chmod -R 755 .cangjie场景5Windows 长路径限制工程路径过长如C:\Users\Name\Documents\Projects\...超过 260 字符Get-ItemProperty -Path .cangjie -Name AttributesPowerShell启用 Windows 长路径支持组策略编辑器 → 计算机配置 → 管理模板 → 系统 → 文件系统 → 启用“Win32 long paths”场景6插件缓存污染VS Code 的插件缓存损坏导致初始化状态丢失删除~/.vscode/extensions/vscode-cangjie-*目录卸载插件 → 重启 VS Code → 重新安装插件 → 重新初始化工作区场景7多根工作区冲突工作区是多根工作区Multi-root Workspace且.code-workspace文件中未指定cangjie相关配置查看.code-workspace文件中的folders数组将仓颉工程根目录设为第一个folder或在settings中添加cangjie.workspaceRoot: ./my-first-cj-app独家排查技巧当遇到此报错不要盲目重装。先执行Cangjie: Show Logs在日志面板顶部查找Workspace initialization status:这一行。它会明确告诉你失败原因比如Status: FAILED - No .cangjie directory found in /path/to/folder或Status: FAILED - Permission denied to read .cangjie/project.cj。这是最直接的诊断依据。4.2 可视化界面不显示、不刷新、不响应的三大根源可视化界面的问题往往比命令面板更难定位因为它涉及 WebView 渲染、事件监听、状态同步三层机制。根源1WebView 渲染引擎崩溃高频VS Code 的 WebView 基于 Chromium当插件 JS 代码有未捕获异常时整个视图会白屏或显示Cannot load webview。这不是插件 bug是 VS Code 的安全机制。诊断方法按CtrlShiftI或CmdOptionI打开 VS Code 开发者工具切换到Console标签页刷新界面右键 Cangjie Explorer →Reload View查看是否有红色错误堆栈。常见错误是ReferenceError: require is not defined这表示插件试图在 WebView 中使用 Node.js API而 WebView 默认禁用。解决方案插件作者已在 v1.2.1 修复升级插件即可若无法升级临时方案是禁用所有其他 WebView 类插件如 Live Server、Markdown Preview Enhanced减少内存竞争。根源2状态监听失效中频插件通过 VS Code 的workspace.onDidChangeConfiguration事件监听project.cj和build.cj的变化。但如果这两个文件被外部程序如 Git、IDE直接修改事件可能丢失。现象你在外部编辑器里改了build.cj可视化界面没更新或者在界面里改了依赖文件没保存。诊断方法在开发者工具的Network标签页过滤file://查看是否有project.cj的GET请求失败。解决方案始终通过可视化界面修改配置如果必须外部编辑修改后在 VS Code 中右键文件 →Reveal in Explorer→ 右键 →Refresh。根源3CSS 样式冲突低频但致命某些主题插件如One Dark Pro的旧版会全局重置 CSS 变量导致 Cangjie Explorer 的自定义样式失效表现为文字重叠、按钮不可点击。现象界面元素存在但布局错乱鼠标悬停无反馈。诊断方法在开发者工具的Elements标签页选中任意界面元素查看右侧Styles面板检查color、background-color、cursor等属性是否被覆盖。解决方案在 VS Code 设置中搜索workbench.colorCustomizations添加自定义 CSSworkbench.colorCustomizations: { [One Dark Pro]: { cangjie.explorer.background: #1e1e1e, cangjie.explorer.foreground: #d4d4d4 } }4.3 构建失败的典型错误码与速查表当Cangjie: Build或可视化界面构建失败时错误信息往往藏在终端输出的末尾。我整理了最常出现的 5 个错误码及其含义错误码终端输出片段根本原因修复步骤E001error[E001]: unresolved import std::io依赖未解析或版本不兼容进入Dependencies视图右键std依赖 →Resolve Dependency或手动编辑project.cj将std版本改为^0.8.0匹配 CLI 版本E002error[E002]: cannot find function main in this scopeentry字段指向的文件不存在或无main函数检查build.cj中targets.web.entry的路径确保文件存在打开该文件确认有fn main() { ... }声明E003error[E003]: failed to parse build.cj: invalid jsonbuild.cj文件有语法错误如逗号缺失、引号不匹配在 VS Code 中打开build.cj按ShiftAltF格式化或复制内容到 JSONLint.com 验证E004error[E004]: toolchain wasm32-unknown-unknown not installedwasm toolchain 未安装执行cangjie toolchain install wasm32-unknown-unknown或在可视化界面Build Targets中点击web节点旁的Install Toolchain按钮E005error[E005]: output directory dist/web is not writabledist/web目录权限不足或被占用在终端中执行chmod 755 dist/web或关闭所有占用该目录的程序如 Web 服务器、文件管理器终极排查技巧当构建失败不要只看第一行错误。用鼠标拖选整个终端输出复制到文本编辑器搜索error[。你会发现真正的错误往往在倒数第三、四行前面几十行是编译器的冗余日志。把error[E00X]这一行单独复制出来粘贴到插件 GitHub Issues 中搜索90% 的问题都有现成答案。
)
