在Windows上写C/C编译运行一切正常一次部署到Linux服务器上就段错误这种经历我相信不少人都碰到过。放着不管吧线上程序在跑管吧又得在Windows和Linux之间来回切换改一行代码可能要来回传三次。我最早的处理方案是装VMware后来换成Samba共享目录再后来干脆用SSH连上去手工敲命令每一种都谈不上体验。直到我把VSCode的Remote-SSH用法吃透让编辑器直接连到远程Linux主机标题里的ConteOS我按常见的CentOS系来搭C/C的编译和调试全部在远端完成Windows这台机器只负责打字和看代码这个折磨了我很久的流程才算彻底理顺。这篇就把整个配置过程、原理和踩过的坑一次讲清楚。1. 为什么要折腾远程Linux开发本地编译过不等于线上能跑1.1 跨平台C/C开发的典型痛点写C/C的人大多遇到过这类问题Windows上VS编译通过、运行正常代码推到Linux服务器上一编译先出来一堆warning再一跑直接Segmentation fault。原因其实很直白——MSVC和GCC虽然是亲兄弟但底子差很多。先说最基本的整数类型。Windows上long是32位Linux x64上long是64位这是两套平台ABI的关键差异。一个结构体里塞几个long在Windows下序列化出来的字节数跟Linux下完全不同粘包、解析错乱是常有的事。再看编译器对C标准的支持MSVC的C99支持到今天都不算完整可变长数组这种语法在GCC下跑得好好的拿到MSVC直接报错反过来MSVC特有的__declspec、#pragma pack在GCC下也要专门处理。还有动态库和头文件的坑。Windows下你用Visual Studio安装的OpenSSL、libcurl版本跟Linux服务器上的发行版自带的版本经常对不上。本地调用的某个API签名变了或者某个宏定义不同编译那一层就过不去。就算代码能编译glibc和MSVCRT的运行时行为也有细微差别最典型的就是malloc失败后的处理策略、printf浮点格式化的精度差异。更麻烦的是这些问题不是靠细心就能避开的。你本地没有Linux环境就永远不知道GCC会报什么不知道glibc下程序跑起来是什么表现。等代码真上了服务器再回头看报错往往要在SSH终端里来回试一步一个坑。1.2 虚拟机、Samba、手动SSH各自的问题在哪既然需要Linux环境最常见的做法是装虚拟机。VMware或VirtualBox里开一台CentOS环境确实一致了但痛点也很明显虚拟机要单独分配内存和CPU笔记本开个虚拟机风扇狂转两台机器之间剪贴板、文件共享有时候还会出幺蛾子更不用说每次在Windows和Linux之间切换眼睛得在两种桌面环境之间来回适应效率高不了。也有人用Samba共享目录。把Linux服务器的目录挂载成Windows的Z盘直接在VS Code里编辑Z盘上的代码保存到远端。这个方案能解决编辑问题但编译调试还是得另想办法。你可以在远端挂一个终端gcc xxx.c ./a.out报错了再切回Windows看代码。代码多了以后error信息里的行号你要自己记改完了再切过去重编这种割裂体验很容易让人崩溃。还有人直接SSH上去用Vim写代码。Vim写小脚本没问题但C/C项目动辄十几个文件函数跳转、补全、重命名、调试器集成全都要靠一堆插件配置投入的学习成本不比解决跨平台问题低。1.3 Remote-SSH到底做了什么一句话讲清原理Remote-SSH的思路很直接VSCode这层壳运行在Windows上负责渲染界面、响应按键真正的开发环境——文件系统、IntelliSense索引、语言服务、编译调试——全部在远端Linux主机上执行。你在Windows的VSCode里打开/home/dev/project/main.c这个文件其实是从远端通过安全通道拉过来的你按F5启动调试VSCode会在远端调用gdb把断点信息、调用栈实时传回Windows界面展示。带来的好处是决定性的开发环境和运行环境变成同一个编译报错、运行时崩溃都只跟Linux相关跟你Windows上装了什么再无关系。而且不需要维护两份代码不需要同步文件VSCode里看到的目录结构就是服务器上的真实目录结构。配置好一次之后日常使用几乎感觉不到远程的存在就像在本地写代码一样。2. 两端环境准备把远程开发的基础打牢2.1 Windows端VSCode、Remote-SSH插件与ssh客户端Windows端需要三样东西VSCode本体、Remote-SSH扩展包、一个可用的ssh客户端。VSCode从官网下载安装包就行稳定版即可不用追Insiders版。安装完成后在扩展市场搜索Remote - SSH装那个微软官方的扩展包ms-vscode-remote.remote-ssh它会连带装好Remote - SSH: Editing Configuration Files和Remote Explorer。搜索量很大的vscode设置中文装一个Chinese (Simplified) Language Pack扩展就能把界面切成中文。ssh客户端这块Windows 10 1803以后的系统自带OpenSSH客户端绝大多数人不用额外装。怎么确认打开PowerShell或CMD执行ssh -V能打印版本号就说明可用。如果系统里没有或者你更喜欢Git自带的ssh客户端装完Git for Windows后把ssh路径填到VSCode设置里。具体位置是VSCode设置搜索terminal.integrated.shell.windows或直接在设置里搜Remote.SSH: Path填C:\Program Files\Git\usr\bin\ssh.exe这种实际路径。还有一个小细节Remote-SSH扩展在VSCode里会依赖本机的ssh客户端去建立连接所以本机的PATH里必须能直接找到ssh命令。如果远程连接时报找不到ssh多半是PATH里没有OpenSSH的目录通常是C:\Windows\System32\OpenSSH。把目录加进系统PATH重启VSCode即可。2.2 Linux端sshd与编译调试工具链远端Linux主机要装两个东西sshd服务端一般默认有和C/C编译调试工具链。以ConteOS/CentOS系为例用yum或dnf安装sudo yum install -y openssh-server gcc gcc-c gdb make cmake这里每一样都有明确用途工具作用openssh-server让Windows能通过SSH连进来gcc编译C语言ggcc-c编译C语言gdb命令行调试器VSCode远程调试本质是调用它make/cmake构建工具项目大了以后离不开装完之后分别验证一下gcc --version gdb --version cmake --version systemctl status sshd如果sshd没启动执行sudo systemctl start sshd sudo systemctl enable sshdCentOS 7及以下版本可能用service sshd start效果一样。另外检查一下sshd的配置确保允许密码或密钥登录。默认配置通常没问题但如果你之前改过/etc/ssh/sshd_config注意这几项PermitRootLogin yes # 如果要用root登录 PasswordAuthentication yes # 如果要用密码登录 PubkeyAuthentication yes # 如果用公钥登录改完配置记得重启sshdsudo systemctl restart sshd。2.3 网络可达性与防火墙排查环境装好了先确认Windows能访问到Linux主机。最简单的是ping不通就查网络和IP配置。通了再测22端口ssh -v user192.168.1.100-v能打印连接过程卡在哪一步一目了然。如果通了但是连接超时重点查三个地方第一是防火墙。CentOS 7以上默认用firewalldsudo systemctl status firewalld sudo firewall-cmd --add-port22/tcp --permanent sudo firewall-cmd --reload第二是SELinux。getenforce如果显示Enforcingsshd的权限可能会被限制临时测试可以sudo setenforce 0关掉但生产环境不建议这么干。第三是云服务器的安全组规则。很多人第一次用云主机Linux内部防火墙放行了但阿里云/腾讯云的安全组里没放行22端口照样连不上。控制台里找安全组添加入方向规则协议TCP端口22来源填你自己的公网IP或0.0.0.0/0不推荐全局开放按需设置。3. SSH连接配置从密码登录到免密登录3.1 config文件给服务器一个顺手的名字直接ssh user192.168.1.100也不是不行但每次都要打IP服务器多了更是灾难。在Windows的C:\Users\你的用户名\.ssh\config文件里写一段配置就能用别名连接Host mycentos HostName 192.168.1.100 User dev Port 22 IdentityFile ~/.ssh/id_ed25519写完保存终端里执行ssh mycentosVSCode的Remote-SSH连接列表里也会多出这个别名点击即连。需要说明的是HostName写IP或域名都行User是远端登录用户名IdentityFile指向第二步生成的私钥路径没配私钥前可以先不写用密码登录。3.2 公钥免密登录的完整过程密码登录能用但每次连接都要输一遍密码而且VSCode远程插件初始化时还会请求多次体验不好。还要考虑密码在网络上传输的安全性免密登录是必须做的一步。在Windows的PowerShell里生成密钥对ssh-keygen -t ed25519 -C vscode-remote-key一路回车会在C:\Users\你的用户名\.ssh\下生成id_ed25519私钥和id_ed25519.pub公钥。私钥千万保存好别外传。然后把公钥加到远端的~/.ssh/authorized_keys里。Windows没有ssh-copy-id用下面的方式手动追加type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh dev192.168.1.100 mkdir -p ~/.ssh cat ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys这条命令第一次会让你输密码输完公钥就写进远端了。注意PowerShell里type是Get-Content的别名效果一样。之后重新打开一个终端执行ssh mycentos如果没要密码直接进了shell说明免密配置成功。如果ssh-keygen -t ed25519报错说明系统OpenSSH版本太老退而求其次用ssh-keygen -t rsa -b 4096生成RSA密钥后面步骤一样。3.3 连接慢、密钥变更、端口不通的排查记录配置过程中遇到连接问题不用慌逐个排查。连接慢卡在某个环节几秒钟。多半是SSH服务端在做反向DNS解析。编辑远端/etc/ssh/sshd_config加上UseDNS no GSSAPIAuthentication no重启sshd连接速度会明显改善。提示REMOTE HOST IDENTIFICATION HAS CHANGED。这个坑很容易遇到——系统重装、服务器IP被复用或者你重装过Linux本机的known_hosts里残留了旧指纹。终端会拒绝连接并报警。解决办法是删除旧指纹ssh-keygen -R 192.168.1.100如果用了config别名ssh-keygen -R mycentos也有效。然后再连一次会提示确认新指纹输yes。端口不通。telnet ip 22测试如果卡住基本就是防火墙或安全组。注意有些网络环境里ping通不代表端口通TCP连接层面还会被网络策略拦截需要跟网络管理员确认22端口是否放行。密码正确但登录失败。检查/etc/ssh/sshd_config里的PasswordAuthentication是不是yes以及该用户是否允许登录。看详细日志的话journalctl -u sshd -n 50或/var/log/secure会有明确记录。4. IntelliSense的路径优先级为什么结构体成员补全会出错4.1 远程模式的插件部署逻辑第一次通过Remote-SSH连接成功后VSCode会自动在远端主机的~/.vscode-server目录下安装一套VSCode服务端并把已安装的扩展同步过去。注意看窗口左下角连接成功后显示的是SSH: mycentos这个标识代表了当前的远程会话。C/C插件ms-vscode.cpptools比较特殊它同时包含本地UI部分和远程语言服务部分。第一次打开远程C/C项目时底部状态栏可能显示Installing C/C extension这是在远端下载语言服务。这一步偶尔会因为网络原因卡住重试或检查远端网络即可。然后打开远端的代码目录File - Open Folder在弹出的路径框里输入Linux目录比如/home/dev/project。这一步必须关联远端目录不是Windows本地目录。4.2 手工配置includePath和defines打开一个.c或.cpp文件后发现头文件报无法打开源文件或者智能提示一片空白这是C/C插件还没有拿到正确的包含路径。此时按CtrlShiftP输入Edit Configurations (JSON)生成并打开.vscode/c_cpp_properties.json。一份典型的配置长这样{ configurations: [ { name: Linux, includePath: [ ${workspaceFolder}/**, /usr/include/**, /usr/local/include/** ], defines: [], compilerPath: /usr/bin/gcc, cStandard: c11, cppStandard: c17, intelliSenseMode: linux-gcc-x64 } ], version: 4 }includePath告诉插件去哪些目录找头文件。${workspaceFolder}/**覆盖项目自身目录/usr/include和/usr/local/include覆盖系统头文件和第三方库头文件。如果你的项目用了某个自定义库把对应目录追加进来而不是用/usr/include下不存在的路径硬撑。defines里可以预定义宏比如BUILD_VERSION1.0用于某些受宏控制的代码段。compilerPath指向gcc的绝对路径插件会用它探测系统默认头文件路径所以路径要准确。intelliSenseMode要与远端架构匹配远端32位还是64位就用对应的模式。4.3 compile_commands.json让智能提示与真实编译保持一致手动配置最怕的是路径太多、版本太乱配了个寂寞。我在实际项目中体会最深的是头文件搜索路径最好与真实编译命令完全一致否则智能提示的结果和gcc实际编译的结果会有偏差。compile_commands.json就是干这个的。它记录了每个源文件的精确编译指令包括所有-I包含路径、-D宏定义、-std标准。CMake项目最容易生成cmake -DCMAKE_EXPORT_COMPILE_COMMANDSON .或者在CMakeLists.txt里加一行set(CMAKE_EXPORT_COMPILE_COMMANDS ON)之后构建目录里会出现compile_commands.json。如果是非CMake的Makefile项目可以用bear工具包sudo yum install -y bear bear -- make -j8会在当前目录生成compile_commands.json。然后在c_cpp_properties.json里加一行compileCommands: ${workspaceFolder}/compile_commands.json配置生效后C/C插件会优先按照compile_commands.json里的真实编译参数做解析大部分头文件找不到、宏定义诡异的问题都会消失。这个方法强烈推荐比手工维护includePath省心太多。4.4 同名头文件与结构体补全错误的排查思路热搜词里有两条跟这个直接相关vscode c/c智能提示路径优先级和vscode c/c结构体成员补全错误这俩其实是同一个问题的两面。C/C插件的IntelliSense解析#include xxx.h时搜索顺序大致是先当前文件所在目录再按includePath里配置的顺序逐个查找最后是编译器内置路径。如果项目里有两个目录都放了同名头文件includePath里排在前面的目录会先被命中。问题就在这——同一个名字两个目录里的内容不一样一个定义了三成员的结构体另一个只定义了俩成员插件一旦选错你写代码时结构体成员就只补全出一部分甚至编译能过但提示错误反过来提示正确但编译报错。遇到这种情况我的排查步骤是先确认报错文件实际包含的是哪个头文件。Ctrl点击跳转到定义处看路径。检查includePath顺序把目标文件所在目录往前调或者用绝对路径直接指定。最稳的办法让compile_commands.json接管解析让IntelliSense跟随真实编译指令。配置compileCommands后插件的解析路径就与gcc完全一致这个路径优先级问题基本不再出现。5. 构建任务与调试器联动一个F5搞定编译调试5.1 tasks.json把gcc编译指令固化下来远程开发环境下编译指令最终由远端执行。VSCode通过tasks.json把编译当前文件这个动作固化成一个可重复触发的任务。按CtrlShiftP输入Tasks: Configure Default Build Task选择C/C: gcc build active file会自动生成一份模板。我习惯在此基础上手动调整一份典型的tasks.json如下{ version: 2.0.0, tasks: [ { label: C/C: gcc 编译活动文件, type: cppbuild, command: /usr/bin/gcc, args: [ -fdiagnostics-coloralways, -g, -Wall, -stdc11, ${file}, -o, ${fileDirname}/${fileBasenameNoExtension} ], options: { cwd: ${fileDirname} }, problemMatcher: [ $gcc ], group: { kind: build, isDefault: true } } ] }逐项解释一下。command是编译器路径C项目换成/usr/bin/g。args里-g生成调试信息这是后面gdb调试的前提-Wall打开常见警告C/C项目里警告往往能提前暴露大坑-stdc11按项目需要设置。${file}是当前活动文件${fileDirname}是文件所在目录${fileBasenameNoExtension}是去掉扩展名的文件名所以输出可执行文件就跟源码同名不带.exe放到同目录下。problemMatcher里的$gcc告诉VSCode如何解析gcc的报错输出这样编译错误会在问题面板里以列表形式展示双击能跳转到对应行。group里isDefault: true表示按CtrlShiftB会默认执行这个任务。配置好后按CtrlShiftBVSCode会在远端执行编译命令输出可执行文件。这一段编译过程的报错再也不用手动从终端里复制了。5.2 launch.json与gdb的搭桥调试配置在launch.json里。切到运行和调试侧边栏创建launch.json选C (GDB/LLDB)VSCode会自动生成一个基础配置我在此基础上补全如下{ version: 0.2.0, configurations: [ { name: C/C: gcc 构建并调试活动文件, type: cppdbg, request: launch, program: ${fileDirname}/${fileBasenameNoExtension}, args: [], stopAtEntry: false, cwd: ${fileDirname}, environment: [], externalConsole: false, MIMode: gdb, setupCommands: [ { description: 为 gdb 启用整齐打印, text: -enable-pretty-printing, ignoreFailures: true } ], preLaunchTask: C/C: gcc 编译活动文件, miDebuggerPath: /usr/bin/gdb } ] }核心字段program是待调试的可执行文件路径必须与tasks.json里-o输出的路径一致否则gdb找不到要调试的程序。preLaunchTask填的是tasks.json里那个label作用是在按F5启动调试前先执行编译任务保证程序是最新编译的。miDebuggerPath指向远端的gdb路径可以用which gdb查。externalConsole保持false远程模式下用内置终端即可。setupCommands里-enable-pretty-printing是给STL容器用的调试C的vector、map时没有这个选项变量查看器里的数据是裸内存地址有了之后可以按结构展开好用得多。5.3 单文件到多文件的演进从tasks到CMake Tools上面的tasks.json配置适合单文件或文件夹下少量源文件。但实际项目往往是多个.c/.cpp文件组成甚至还有子目录。这时候有几种演进方式。简单的多文件项目可以把args里的${file}改成通配符比如${workspaceFolder}/src/*.c配合-I指定头文件目录直接一条命令编译所有源文件。缺点是这样编译的依赖关系不精确任何文件改动都会全量重编大型项目效率不行。正规一点的做法是引入Makefile或CMake。用Makefile时tasks.json里的command直接改成makeargs清空或只留目标名{ label: make: 构建项目, type: shell, command: make, args: [], options: { cwd: ${workspaceFolder} }, problemMatcher: [$gcc], group: { kind: build, isDefault: true } }用CMake时我更推荐直接装CMake Tools扩展。它能把CMakeLists.txt里的构建配置变成图形化操作底部状态栏能选编译套件Kit、点Build构建、点Launch调试。CMake Tools生成的调试配置会自动指向构建目录里的可执行文件省去手写launch.json的路径坑。对C/C项目来说从单文件到CMake这个演进路径是最平滑的。6. 实测里高频踩坑的五个问题6.1 中文乱码文件编码、终端输出与解压文件名远程开发把文件和程序都搬到了Linux上中文编码问题一下子多出来三个表现。第一个代码里中文注释乱码。远程模式下VSCode新建文件默认UTF-8但老项目很可能是在Windows上用GBK编码存的。解决方式是右下角状态栏点一下UTF-8选择通过编码重新打开Reopen with Encoding再选GBK或GB2312注释就正常了。如果你手上的项目一直是GBK编码老项目可以在设置里把Files: Encoding改成GBK作为默认但我会建议能转UTF-8就尽早转否则后面跟Linux工具链的兼容性全是暗伤。第二个程序运行输出中文乱码。Linux终端里printf(中文)显示成????或者乱码多半是locale没设成UTF-8。检查echo $LANG如果不是en_US.UTF-8或zh_CN.UTF-8在/etc/locale.conf里设置或者用户级~/.bashrc里export LANGen_US.UTF-8重开终端生效。第三个从Windows拷贝zip压缩包到Linux解压中文文件名变成乱码。原因是Windows压缩时文件名用的GBKLinux的unzip按UTF-8解。解决方案是用unzip -O GBK file.zip或者改用7z x file.zip。被这个坑折磨过的朋友应该能感受到这三个乱码任何一个都会让人怀疑人生。6.2 断点不生效-g、优化级别与程序路径调试的时候最怕的就是断点打上去了程序跑过去毫无反应。这个问题的常见原因按出现频率排序第一编译时没加-g参数。这是最高频的。检查tasks.json的args里有没有-g没有就补上。没有调试信息gdb不知道哪一行对应哪条机器指令断点自然不生效。第二编译优化级别太高。-O2及以上的优化会让编译器和gdb抢功劳单步执行时你会看到代码行跳来跳去甚至某些局部变量在优化后被删了查看值报value optimized out。调试阶段建议用-O0发布时再开优化。第三program路径和实际可执行文件路径对不上。注意检查launch.json里的program是不是指向了正确的输出文件。如果有多个配置或者目录结构调整过这是常见的看起来没问题但就是断不上的原因。第四多进程程序。程序里调用fork()后gdb默认跟随父进程还是子进程需要显式设置。可以在setupCommands里加set follow-fork-mode child或parent按实际需求切换。第五动态库里的断点。如果调试的代码在.so动态库里而该库编译时没加-g符号信息缺失断点照样不生效。这种情况需要重新编译动态库确保带调试信息。6.3 需要标准输入的程序怎么调试C/C命令行的经典程序很多都依赖scanf或cin。在VSCode远程调试模式下externalConsole设为false时程序的标准输入没法直接在调试控制台里敲——至少在我用过的多个VSCode版本和Remote-SSH组合里这就是个老大难。新手经常卡在这一步以为配置错了。我的做法分三种。第一种有输入文件的场景。如果程序从文件读输入调试前在终端里生成好测试数据文件然后在launch.json的args里加重定向args: [, /home/dev/project/input.txt]gdb在启动时会自动把input.txt作为标准输入喂给程序调试体验和普通程序无异。第二种必须交互输入的场景。调试逻辑时先用注释临时把输入改为硬编码或者写一个固定文件路径等调试完再改回来。虽然不优雅但胜在直接。第三种只验证输出结果的场景。直接在VSCode内置终端里运行程序输入数据看结果需要定位问题时再为特定分支条件加断点用上面两种方式启动调试。6.4 CMake项目的launch路径问题用CMake Tools构建时可执行文件默认输出到build/目录。很多人在launch.json里program还写的是源码目录的路径比如${workspaceFolder}/main结果调试启动时报错找不到程序。正确做法是确认CMakeLists.txt里add_executable的目标名比如add_executable(myapp src/main.c src/utils.c)那么可执行文件在构建目录下launch.json里program应该写成program: ${workspaceFolder}/build/myappcwd建议也改成${workspaceFolder}这样程序运行时相对路径的文件访问行为跟直接在项目根目录运行一致。如果你不想手写可以用CMake Tools扩展的调试入口它会根据CMake配置自动生成正确的launch.json路径一般不会错。6.5 SSH频繁断开与KeepAlive配置用Remote-SSH一段时间后闲置久了连接会掉VSCode底部弹Reconnecting提示。频繁重连除了烦人还会打断调试会话。这个问题本质是连接双方中间的防火墙或NAT设备把空闲连接掐了。解决办法是发心跳包。在你本机的~/.ssh/config对应Host段下加Host mycentos HostName 192.168.1.100 User dev Port 22 ServerAliveInterval 30 ServerAliveCountMax 3ServerAliveInterval 30表示客户端每30秒发一个保活包防止中间网络设备认为连接已死。同时也可以在远端/etc/ssh/sshd_config里配置ClientAliveInterval 60 ClientAliveCountMax 3两个都配好重启sshd重连一次。之后再闲置很长时间连接基本不会断。7. 这套开发方式还能怎么延伸7.1 端口转发把远端服务映射到Windows本地调试C/S架构的C/C程序时经常遇到远端程序监听某个端口但你想在Windows浏览器或客户端里直接访问。比如远端跑了个HTTP服务监听8080端口。在.ssh/config里给Host段加一行LocalForward 8080 localhost:8080重连SSH后Windows浏览器访问http://localhost:8080流量就被安全通道转发到远端的8080端口。这个功能调试Web服务、MySQL连接、Redis客户端都特别方便。VSCode里也有图形化替代方案Remote-SSH连接后切到端口视图输入远端端口VSCode自动映射到本机随机端口点按钮就能打开浏览器。7.2 从远程主机到远程容器如果你的开发环境是Docker容器Remote-SSH连上宿主机后还可以结合Remote - Containers扩展直接进入容器开发。再配合gdb的容器内调试就能做到代码在容器里编译调试器进容器里跑界面还在Windows。这套组合对多版本编译工具链的验证非常有用——同一套代码在CentOS 7容器里编一次在Ubuntu 22.04容器里再编一次随时切换互不影响。最后说一点个人体会。用这套模式久了最大的感受不是省了来回传代码的时间而是心态变了——以前遇到只在服务器上出现的崩溃第一反应是害怕因为本地根本复现不了现在遇到线上问题我直接在VSCode里连上服务器打开对应程序gdb定位整个链路都是熟悉的。如果你想入坑远程开发就从这篇配置开始先跑通一个hello.c再慢慢把includePath和调试配置按自己项目修正遇到报错耐心看日志。这套东西弄熟之后你多半会和我一样回不去本地开发了。