拉下一个 iOS 项目，文件夹里可能同时躺着 .xcodeproj、.xcworkspace、Podfile、Package.swift，有的还套着 Flutter 或 React Native 目录。想用 VS Code 打开，第一个问题不是插件装没装，而是：它到底认不认这个工程。
这篇就把 KXApp 支持哪些项目讲清楚，按工程类型、工作区、依赖和目录结构四件事展开。先给一张表，后面逐项说。
| 你的项目长什么样 | 能不能用 | 说明 |
|---|---|---|
.xcodeproj | 能 | 打开工程所在文件夹即可 |
.xcworkspace（CocoaPods 等） | 能 | 同名工作区和工程并存时，优先用工作区 |
| Xcode 工程 + Swift Package Manager 依赖 | 能 | 依赖跟着工程解析，仍按 Xcode 工程构建 |
| 纯 Swift Package，没有 App 工程 | 不在覆盖范围 | 资料没有把它列为独立项目类型，别默认能一键跑真机 |
| Flutter / React Native / uni-app 项目 | 不在资料覆盖范围 | 即使里面有 iOS 目录，也不要把跨端工作流当成已支持 |
| Windows / Linux 上的项目 | 不能 | 只支持 macOS |
先说明一句：这张表判断的是「工具的覆盖范围」，不是「Xcode 能不能打开」。Xcode 能开的类型更多，资料只承诺了 Xcode 工程这一层。
认工程：看的是 .xcodeproj 和 .xcworkspace
用「文件 › 打开文件夹…」打开含有工程文件的目录，工程在子目录里也能识别。识别到之后，活动栏出现「Xcode 工程」视图，状态栏显示 Scheme、构建配置和运行目标。
同名的工作区和工程同时存在时（CocoaPods 项目经常这样），工具会自动用工作区。文件夹里有多个不同的工程，就在视图的「工程」那一行切换。项目不用迁移，也不会生成新的工程文件，回到 Xcode 打开还是原来那份。
其实这一层的判断标准很朴素：目录里有没有 .xcodeproj 或 .xcworkspace。有，才有后面的事啊。
依赖：CocoaPods 和 Swift Package Manager 跟着工程走
CocoaPods 工程认的是 .xcworkspace，不是 .xcodeproj。打开前先确认执行过 pod install，不然依赖没解析，构建和补全都会出问题。
Swift Package Manager 的依赖由 Xcode 工程解析，工具还是按工程里的 Scheme、配置和构建设置来构建。第三方库要构建过才有完整补全；项目没构建过时，插件会在后台准备一次索引，见代码补全那一套流程。
依赖管理器和项目类型是两回事。有 Podfile 不等于有工程，有 Package.swift 也不等于这是一个能直接跑真机的 App 工程。判断时还是回到上一节：有没有 Xcode 工程呢。
不支持什么：跨端项目和别的系统
新资料只描述 Xcode 工程。Flutter、React Native、uni-app 这些跨端项目，即使里面带着 iOS 目录，也不要按「支持跨端工作流」去理解——资料没覆盖，确实不该替它承诺。
Windows 和 Linux 也不行。它是 macOS 上的 VS Code 扩展，另两个系统装不了，这不是配置问题。
还有一种容易误判的：纯 Swift Package 或者静态库，没有 App target。Xcode 能打开，但「一键跑真机」不是为这种项目设计的，别拿它当完整的 App 工程用。
别把 KXApp 当成全能打开器。它认的是 Xcode 工程，不是所有能在 Xcode 里打开的目录都等于完整支持；跨端框架和别的操作系统，文档没有承诺，就不要按「应该能」去用。
多个工程、多个 target：怎么切
一个文件夹里放了好几个工程，视图里的「工程」行可以切换；选中哪个，对应的 Scheme、配置、运行目标和 Targets 就跟着变。
Target 列表会把工程里的各个 target 列出来，运行的时候选的是 App 对应的 Scheme。切换 Scheme 或构建配置后，代码补全也会按新的配置重新计算，不用手动刷新。
如果你的仓库里有主 App 和一堆扩展、框架 target，先确认运行的是主 App 的 Scheme；target 本身不是运行入口，别在列表里点错吧。
怎么确认你的项目能不能用
按这个顺序查，比在设置里乱翻快：
- 打开的文件夹里有没有
.xcodeproj或.xcworkspace； - 运行
xcode-select -p，输出是不是在Xcode.app里面； - 新装的 Xcode 有没有至少打开过一次，把附加组件装完；
- 打开文件夹后，活动栏有没有出现「Xcode 工程」视图；
- 按
Cmd+B构建一次，看「问题」面板和构建日志。
没有工程视图时，先看前三条。Pods、node_modules、build、DerivedData 目录下的工程不会被识别，别把项目根指到这些目录上嘛。
和 Xcode、Cursor、VSCodium 比一比
Xcode 是这套工程信息的源头，所有工程类型、构建阶段、Interface Builder、Instruments 都在它里面。要在 Mac 上做完整的 iOS 开发，它绕不开。
VS Code 加这个插件覆盖的是 Xcode 工程这一层：打开、构建、跑真机、调试、补全、测试、改配置。跨端框架的完整工作流和 Windows / Linux 不在范围内，这一点得接受。
Cursor、VSCodium 这类编辑器，从 Open VSX 装同一个插件，支持范围一样，不会因为换了编辑器就多出跨端能力。
KXApp 支持哪些项目，判断标准就两条：有没有 Xcode 工程，以及你在不在 Mac 上。两条都满足，打开文件夹、看到工程视图、构建一次，基本就能用；缺一条，换工具比硬试快啊。
项目类型不用记一长串，记住 .xcodeproj 和 .xcworkspace 这两个后缀就够了。依赖是 CocoaPods 还是 Swift Package Manager，那只影响打开哪个文件、要不要先构建，不改变支持范围。
