了解示例应用画廊（01 Get to Know the Sample Gallery）
本单元了解我们为什么构建 Trailhead 示例应用、它们存放在 GitHub 哪里、两种大类应用（用例应用和代码示例应用），以及如何从示例画廊导航到实际仓库。
完成本项目后，你将能够：
- 了解示例应用；
- 了解它们在哪里、为什么构建它们；
- 走一遍常见的示例应用工具。
注意：开发者网站和示例应用在持续开发，一些图片或细节（如版本号）可能与项目里呈现的略有不同——这不影响完成项目。
Trailhead 示例应用（Trailhead Sample Apps）
对开发者来说，看别人的代码是学习「怎么让东西跑起来」的久经考验的方法——对初学开发的人也一样。
Trailhead 示例应用在 Salesforce 平台的各类开发者特性上提供代码示例。我们构建这些应用是为了帮你快速上手最新最强的 Salesforce 技术——与其从空白页开始，不如读现成的代码、运行它、再改编到自己的项目里。
找到示例应用（一）：GitHub 组织（Find the Sample Apps (1): The GitHub Org）
Trailhead 示例应用存放在它们自己的 GitHub 组织里。找到它们很简单：
- 打开浏览器；
- 访问
github.com/trailheadapps； - 搞定！组织登录页就是所有示例应用的目录。
找到示例应用（二）：关于持续开发的说明（Find the Sample Apps (2): A Note on Constant Development）
我们的开发者网站和示例应用在持续开发中，所以：
- 一些图片或细节（如版本号）可能与项目里呈现的略有不同；
- 这是预期中的，不影响你完成项目。
关注概念，不必纠结于确切的像素。
你在 Trailhead 示例应用组织里会发现（一）：面向所有开发者（What You'll Find (1): Built for All Developers）
首先要知道：Trailhead 示例应用面向所有学习 Salesforce 技术的开发者，每个都能独立作为资源使用。每个应用包含自导资源帮你熟悉其内容：
- 在 VS Code 里查看时，有 code tour 在编辑器里带你走一遍关键代码工件；
- 部署到组织后，可通过 In-App Guidance 学习应用。
许多应用在 Trailhead 模块和项目中反复出现——有些是专为支持 Trailhead 内容创建的，有些是创建后被 Trailhead 作者采纳为常用用例。浏览画廊，展开每个应用瓷砖的 Description and Features 阅读。
你在 Trailhead 示例应用组织里会发现（二）：两类应用（What You'll Find (2): Two Kinds of Apps）
滚动画廊，你会看到两类应用：
- 用例应用（Use case apps）——围绕一个模拟的客户用例构建，聚焦人们想学的某个 Salesforce 平台开发者特性子集（如 Communities、Heroku、Slack 集成、打包与依赖）。例如 Coral Cloud，它模拟真实的客户场景；
- 代码示例应用（Code example apps）——展示如何解决编码问题，但不一定讲客户故事。
你在 Trailhead 示例应用组织里会发现（三）：Recipes 及更多（What You'll Find (3): Recipes & More）
一些代码示例应用使用我们称为 Recipes 的风格：
- 每个 recipe 解决一个特定问题；
- 展示解决它所需的最简代码；
- 每个代码工件（如 JS 文件或 Apex 方法）以它解决的问题命名。
例如 LWC Recipes 里有个组件叫 wireGetRecordStaticContact——用 wire adapter 以静态字段名获取联系人记录。除 LWC Recipes 外，还有 Apex Recipes、Functions Recipes、LWC Recipes Open Source。其它代码示例应用（如 Visualforce to LWC、Automation Components）演示特定模式。
示例应用代码仓库（一）：从目录到仓库（Sample App Code Repositories (1): From Directory to Repo）
GitHub 组织登录页是活跃示例应用的目录：
- 一眼看到所有应用；
- 点进感兴趣的仓库。
试试：滚动到 LWC Recipes 应用瓷砖，点击应用名 LWC Recipes，你会被重定向到 lwc-recipes GitHub 仓库——应用的全部源码和配置都在那里。
示例应用代码仓库（二）：活跃应用与归档仓库（Sample App Code Repositories (2): Active Apps & Archived Repos）
除了积极维护的应用，我们多年来还归档了一些应用：
- 点击返回按钮；
- 点击 GitHub 导航栏里的 Repositories 链接；
- 你会看到许多其它公共仓库。
其中一些对某些开发者有参考价值，但请记住：我们不再积极维护这些归档应用。下一单元了解这些应用背后的公共工具。
了解示例应用工具（02 Learn About Sample App Tooling）
本单元走一遍大多数示例应用共享的工具和配置，以 LWC Recipes 仓库为例。我们看 Salesforce 项目配置、基于 npm 的代码质量工具、单元测试、代码格式化、忽略规则和 GitHub Actions CI。
Salesforce 项目配置（一）：sfdx-project.json（Project Config (1): sfdx-project.json）
先了解 sfdx-project.json 里的 Salesforce 项目设置。点击仓库里的链接查看内容，注意 packageDirectories 配置：示例应用设置了 unlocked packages，配置含包名、包元数据文件路径和版本信息。这个文件告诉 Salesforce CLI 项目如何组织，是学习示例应用结构的第一站。
Salesforce 项目配置（二）：sourceApiVersion（Project Config (2): sourceApiVersion）
第二个重要配置是 sourceApiVersion——它告诉项目元数据面向哪个 API 版本。作为规则，我们把示例应用更新到当前主要版本的 API 版本，并统一应用到配置文件和所有元数据。所以你看到的值可能和本项目不同——它反映当前版本。看完点击浏览器返回按钮。
代码质量工具设置（一）：npm 用于开发工具（Code Quality Tool Setup (1): npm for Developer Tools）
除了 Salesforce CLI 自带工具，示例应用还用一些基于 npm 运行的工具。即使大多数项目在运行时 Salesforce 代码里不用 Node.js，我们仍带一个 package.json 来用 npm 导入和配置开发工具。
npm 是 Node.js 的默认包管理器，由包注册表、CLI 和 npmjs.com 网站组成，广泛用于构建开发工具——甚至 Salesforce CLI 和 OCLIF 框架都是用它构建的。安装 npm 最简单的方式是安装 Node.js（自带 npm）。
代码质量工具设置（二）：devDependencies（Code Quality Tool Setup (2): The devDependencies）
打开 package.json：
dependencies缺席——示例应用只用开发工具，不用运行时 npm 包；devDependencies里是工具：prettier（格式化）、eslint（lint）、@salesforce/sfdx-lwc-jest（测试 LWC 的 Jest 扩展）、husky（提交前执行代码验证动作）。
代码质量工具设置（三）：封装的脚本（Code Quality Tool Setup (3): Encapsulated Scripts）
除了列出工具，package.json 的 scripts 配置还封装了常用命令，每个用 npm run 执行。例如 test:unit 脚本运行 LWC 单元测试：npm run test:unit。Prettier 等工具也有类似脚本。这个模式让你不用记底层命令，只需运行命名脚本。看完点击返回按钮。
单元测试配置（一）：Jest 与 sfdx-lwc-jest（Unit Testing (1): Jest & sfdx-lwc-jest）
示例应用用 Jest 测试库运行 LWC 单元测试，Salesforce 为 LWC 量身打造了扩展 sfdx-lwc-jest。打开 jest.config.js：moduleNameMapper 对象扩展了 sfdx-lwc-jest 自带的默认 mock。例如 ^lightning/navigation$ 键定义其 mock 位置为 <rootDir>/force-app/test/jest-mocks/lightning/navigation。接下来去仓库里找这个 mock 代码。
单元测试配置（二）：跟踪 Mock 代码（Unit Testing (2): Follow the Mock Code）
跟着 mock 找到源头：
- 点击浏览器返回；
- 依次点击文件夹 force-app → test/jest-mocks → lightning；
- 打开
navigation.js。
你会看到 Lightning NavigationMixin 提供的一些导出函数被 mock 了，以便在 Jest 测试里可预测地运行——单元测试无需访问真实导航服务。看完点击返回四次回到项目根目录。
自动代码格式化配置（一）：Prettier（Formatting (1): Prettier）
接下来是 Prettier 代码格式化工具。与只测 LWC 的 sfdx-lwc-jest 不同，Prettier 格式化很多文件类型：JavaScript 等，还加了 XML 和 Apex 插件，LWC 特定格式化规则随 Prettier 打包。回看 package.json，Prettier 脚本被配置为一次对多种文件类型运行。
自动代码格式化配置（二）：.prettierrc（Formatting (2): .prettierrc）
打开 .prettierrc 文件看配置：强制尾逗号、允许单引号、设置制表符宽度等。它还可用 overrides 键创建自定义解析规则——例如用 lwc 解析器处理花括号包裹的 HTML 属性。更多选项见 Prettier 文档。看完点击返回。
忽略这些（一）：忽略文件（Just Ignore This (1): The Ignore Files）
很多工具让你定义例外——哪些文件它们不执行。Git、Prettier、ESLint 和 Salesforce CLI 都需要知道哪些文件要忽略。项目根目录有三个忽略文件：
.gitignore（Git）；.prettierignore（Prettier）；.forceignore（Salesforce CLI）。
每个为不同工具定义忽略规则。
忽略这些（二）：.forceignore（Just Ignore This (2): .forceignore）
.forceignore 因源码跟踪而重要：对 scratch org 开发时，一个 API 跟踪本地和组织里做的改动，组织与项目可用 sf project deploy start / sf project retrieve start 自动同步。你不想同步的项目部分就在 .forceignore 里配置——其中定义的项不会被 SourceSync API 跟踪或同步。例如示例应用不同步任何 settings 元数据。看完点击返回。
GitHub Actions（一）：CI/CD 自动化（GitHub Actions (1): CI/CD Automation）
好的工具还能在 CI/CD 流程里自动运行。示例应用用 GitHub Actions 在代码合并、在分支间流转时自动执行这些工具。GitHub Actions 是 GitHub 内置功能，可在 GitHub 内定义整个 CI/CD 流程。不过 Salesforce 开发工具对 CI/CD 工具无关——若偏好其它平台，文档有其它示例项目可参考。
GitHub Actions（二）：查看工作流运行（GitHub Actions (2): See the Workflow in Action）
找到工作流并看它运行：
- 点击
.github目录，再点workflows查看 CI 工作流的 YAML 文件； - 打开
ci-pr.yml，找到run: npm run prettier:verify这行——这是 CI 里 Prettier 检查代码是否符合格式规则的地方； - 点击 GitHub UI 顶部的 Actions 标签，左侧是所有工作流运行列表，点击 CI 查看该工作流每次执行。
你已完成 lwc-recipes 仓库的工具之旅，可以开始在任何示例应用里使用这些工具了。
关于 Salesforce 开源的一句话（一）：谁在维护（Open Source at Salesforce (1): Who Maintains Them）
trailheadapps GitHub 组织里的示例由 Salesforce 开发者关系团队开发维护，遵循最佳实践构建，所有应用都演示了符合真实项目预期的工具配置。我们让各应用的工具体配置尽可能统一——个别应用用不同配置，可通过完成 Discover Trailhead Sample Apps trail 里的其它项目了解。
关于 Salesforce 开源的一句话（二）：深入探索（Open Source at Salesforce (2): Go Deeper）
探索完示例应用后，鼓励你深入挖掘 Salesforce 团队更多的代码：可在 Salesforce 开发者网站的 Code Samples and SDKs 网页找到开源代码。你现在知道了示例应用在哪里、为什么存在、如何构建——可以开始自己阅读和改编这些应用了。