接手一个五年前的 Objective-C 项目，打开 Xcode 满屏黄色警告，改一个文件还要等索引；想换到 VS Code，又担心补全不准、断点打不上、CocoaPods 工程认不出来。这篇就讲老项目怎么做 Objective-C 开发，用 KXApp 在 VS Code 里补全、构建、下断点，
先看老项目属于哪一类
老项目不是一个模子刻出来的，先对一下自己是哪一类：
- 纯 OC 工程：只有 Objective-C，没有 Swift，依赖不多
- OC + Swift 混编：有桥接头文件，两边互相调用
- C/C++ 静态库或底层代码：音视频、编解码、算法库常见
- CocoaPods 依赖多的工程：工作区里一堆 Pods，补全经常缺模块
说实话，四类工程的补全和构建前提不完全一样，下面分开说。判断方法不复杂：看工程里 .m、.mm、.swift 的比例，看有没有 Podfile 和 Pods 目录，再看有没有 C++ 源码。别拿纯 OC 的经验套到 CocoaPods 工程上。
第一类：纯 OC 工程
用 VS Code 打开含 .xcodeproj 或 .xcworkspace 的目录，活动栏出现 Xcode 工程视图，说明工程被识别了。项目不用迁移，也不会生成新的工程文件，回到 Xcode 打开还是原来那份。
补全、跳转定义、悬停文档和实时报错都有，第一次打开工程要先等后台索引建完。索引没建好之前，跳转可能没反应，别急着怀疑插件嘛。
纯 OC 工程的依赖一般不多，等索引跑完就能正常写。Activity 栏的 Xcode 工程视图能列出 target 和 Scheme，切 Scheme 之后补全会按新配置重算。头文件路径复杂的老项目，索引时间会更长；工程里的 .pch 预编译头如果有错，补全也会跟着不准。构建、签名、安装还是交给本机的 Xcode，它负责把入口搬到 VS Code 里。它不是把 OC 变成 Swift，只是把编辑和调试搬到了另一个编辑器。
第二类：OC + Swift 混编
混编工程多了一个桥接头文件，两边的方法和类型会互相出现。补全和跳转覆盖 Objective-C 和 Swift，但混编工程的索引比纯 OC 重，第一次打开多等一会儿是正常的呢。桥接头文件里的声明，索引也会带到 Swift 侧。
如果 Swift 里跳不到 OC 的声明，先确认工程构建过、索引建完了；还不行就运行「重启代码提示」或者「重建项目索引」。桥接头文件本身有语法错误时，补全也会跟着乱，先把编译错误清掉再看。
第三类：C/C++ 静态库与底层代码
音视频、编解码、算法这类老项目，底层很多是 C 或 C++。KXApp 的补全覆盖 C 和 C++，断点也能下在 C/C++ 代码里；Objective-C++ 的 .mm 文件同样能调试。C++ 的模板、命名空间这些，补全和跳转也能用；模板展开很深的代码，索引慢一点是正常的。
这一类最容易遇到扩展冲突。装了 clangd 之后，clangd 和它会同时给补全结果，两边打架。解决办法二选一：停用其中一个扩展，或者在 kxapp.swiftSourcekitLspSupportedLanguages 里把 C/C++ 去掉，让 clangd 接管。
扩展冲突的表现很像「补全不准」：同一个符号出现两份候选、跳转跳到奇怪的位置。先看装没装 clangd，比反复重建索引快（别问我怎么知道的）。
第四类：CocoaPods 依赖多的工程
CocoaPods 工程认的是 .xcworkspace，不是 .xcodeproj。打开前先确认执行过 pod install，不然依赖没解析，补全和构建都会出问题。
三方库要构建过才有完整补全。第一次打开工程，后台会准备一次索引，先等它跑完。报 No such module 的时候，先看是不是依赖还没构建，别一上来就重装插件。Pods 工程第一次 pod install 之后，最好先构建一次，让依赖产物和索引对齐；只等索引不构建，补全可能还是缺模块。
工程根目录的 buildServer.json 是补全用的，可以加进 .gitignore。如果它属于别的构建服务器，插件不会接管，删掉再重开窗口就行，挺省事的。
断点、lldb 控制台与 App 输出
OC、C、C++ 都能下断点，条件断点和日志断点也能用。调试工具栏里有变量、监视、调用栈和线程，调试控制台可以输入 lldb 命令，po self、bt 这些都能直接用。条件断点适合循环里只看某个值，日志断点适合不想停下来的场景；两者的用法和 Xcode 里差不多。
App 的 print、NSLog 输出在「输出 › kxapp Console」，构建日志在「输出 › kxapp Build」。改了代码之后，调试工具栏上的「重启」不会重新编译，得重新按 Cmd+R 跑一遍，这点挺坑。
调试体验和 Xcode 不完全一样，但日常看变量、跟调用栈、打条件断点够用。真有底层问题要查，还是回 Instruments 更专业。
和 Xcode、clangd 的分工
Xcode 仍然是 Interface Builder、Storyboard/XIB、Instruments 和签名疑难问题的主场。老项目里的界面文件、性能分析、证书和描述文件的边角情况，印象里，回 Xcode 处理更稳。Xcode 的调试器和它用的是同一套工程配置，断点位置、变量查看的口径基本一致；差别在界面和操作习惯。
clangd 是 C/C++ 的另一套补全方案，配置灵活，适合纯 C/C++ 的工程；和它同时开就要处理冲突，按上一节的办法二选一。
KXApp 是日常编辑和调试这一方面：打开现有工程，补全、跳转、构建、真机断点、lldb 控制台都在 VS Code 里，项目不用迁移。它不是 Xcode 的完全替代，也不负责界面编辑和 Instruments；分工清楚，用起来才顺。
Storyboard 和 Instruments 仍回 Xcode
它是 macOS 上的 VS Code 扩展，用本机的 Xcode 来构建和调试，所以 Mac 和 Xcode 还是得有。它不编辑 Storyboard/XIB，也不带 Instruments；界面和深度性能分析回 Xcode。
第一次打开老工程，索引和依赖准备要花点时间，这不是插件坏了，别瞎折腾。索引没建完、依赖没构建、clangd 冲突，是三个最常见的「补全坏了」原因；按这个顺序查，比反复重装插件快。把工程构建一次、等索引跑完，补全和跳转基本就正常了。
先确认工程类型，用 VS Code 打开 .xcodeproj 或 .xcworkspace；等后台索引建完，需要的话手动构建一次；补全不对就重启代码提示、重建索引；C/C++ 工程先处理 clangd 冲突；断点下在 OC/C++ 代码里，lldb 命令在调试控制台用；界面和 Instruments 的事回 Xcode。
