> ## Documentation Index
> Fetch the complete documentation index at: https://lovable.generaltranslation.app/llms.txt
> Use this file to discover all available pages before exploring further.
# 调试提示词
> 调试工作流，包括策略、示例提示词、故障排除流程，以及深度调试思维模式示例。
使用 AI 构建应用既快速又有趣——直到出现问题为止。错误、意外行为，或者“AI 表现得很奇怪”的瞬间，都是过程的一部分。本指南将帮助你掌握 **在 Lovable 中基于 AI 的调试工作流**。我们会介绍如何快速修复简单问题、应对棘手 Bug 的策略、如何使用 Lovable 的聊天功能进行调试，以及用提示词“配方”系统性地消灭 Bug。和 AI 助手一起调试是一项新技能，但只要有清晰的结构和合适的提示词，你就能高效解决问题，甚至把问题转化为学习机会。
## 高级调试提示词
有时你需要一个更“重型”的提示词来深入排查问题，或全面检查项目的运行状况。下面是一些适用于深度调试或优化场景的结构化提示词示例。你可以在 Chat mode 中使用这些提示词，以获得详尽的分析，而不会立即修改代码。
### 全面系统审查（代码库审计）
如果你的项目已经变得很大，或者你怀疑存在结构性问题，那么使用一个完整的代码库审计提示会很有用。它会让 AI 分析整个项目的整洁度、架构是否合理，以及是否有代码被放在不该放的位置。就像是在问：“现在的一切是否都组织得合理？”
**示例提示 – 代码库审计：**
```
对整个代码库进行全面**审查**，检查架构是否清晰、模块化且经过优化：
- 识别任何位置不当或可以更好组织的文件、组件或逻辑。是否存在不应该出现在当前文件中的代码（逻辑放置错误）？
- 评估是否实现了清晰的关注点分离（例如：数据处理 vs UI vs 状态管理）。指出任何过度耦合的代码部分。
- 标出代码中任何过于复杂或未遵循最佳实践的区域。
- 提供一份报告，包含改进结构和可维护性的具体建议，**但暂时不要进行任何代码更改**。
将建议分解为我们可以采取的有序步骤列表，从最关键的到可选的优化。
*（这是只读分析；在审查期间请勿修改代码。）*
```
这个提示词虽然很长，但它会引导 AI 充当代码审查者或架构师。我们让它去寻找放错位置的代码、检查模块化程度，甚至为修复项排优先级。AI 可能会给出类似这样的回答：
* \_“1. ****将 API 调用从组件中分离：**** The \_`ProjectList`*component is directly fetching data. Suggestion: move data fetching to a dedicated hook or context to keep components pure UI.*
1. **将 API 调用从组件中分离：** `ProjectList` 组件正在直接发起数据请求。建议：将数据获取逻辑移动到专用的 hook 或 context 中，以保持组件只负责展示 UI。
2. **降低 Task 逻辑的耦合度：** 任务完成状态的切换既在更新 state，又在直接写入 localStorage。应当重构为只有一个单一的数据源。
3. **整理工具函数：** `App.tsx` 中有一些工具函数，更适合放在一个 `utils` 文件夹中（例如日期格式化函数）。
4. ...”\*
每一点可能都会带有解释，甚至会引用到具体的文件位置。这样的报告可以帮助你跳出细枝末节，从全局视角审视代码结构。尤其当你一直在逐个功能地开发、很久没有回头看整体结构时，它会格外有用。
避免使用过于笼统、模糊的提示词
```
什么都不好用，帮我全都修好！
```
让你的提示词更具体、更有细节
```
现在屏幕变成空白了，而且我已经无法继续编辑。
你能帮我检查发生了什么吗？
```
拿到这样的输出之后，你就可以决定要先处理哪些重构任务（甚至可以继续提示 AI，逐条帮你实现这些改进建议）。
### 针对易出问题更新的安全做法
当你知道自己正在修改的部分比较敏感（比如复杂的认证流程或核心算法），在提示前面加上一条*警示性指引*是明智的做法。它本身不会直接帮你找出 bug，但可以通过要求 AI 特别小心来预防问题。我们在提示库章节里看过一个关于锁定文件的示例。下面是一个类似的模式，但重点是避免破坏现有功能。
**提示示例 – 易出问题更新指引：**
```
下一个更改涉及**应用的核心部分**,请务必**格外谨慎**。
- 在进行更改*之前*,仔细检查所有相关代码和依赖项。
- **避免修改**无关的组件或文件。
- 如有任何不确定之处,请暂停并在继续之前说明你的思路。
- 更改后务必进行全面测试,确认未影响其他功能。
**任务:** 更新用户身份验证逻辑,在保留现有邮箱/密码登录方式的基础上,新增 Google OAuth 登录支持,确保两种登录流程均正常运行。
*(实施过程中务必格外小心,仔细检查每个步骤。)*
```
通过加入斜体的指导语和加粗的警告，你其实是在为 AI 设定一种更加谨慎的“思维模式”。这样一来，AI 可能会采取更稳妥的方式，例如先解释它打算怎么做，或者在实现 OAuth 集成的同时，明确说明它保留了原有的邮箱/密码登录方式。这个提示并不会立刻产出一个完整的解决方案；相反，它影响的是 AI *执行任务的方式*，以尽量减少引入新 bug 的风险。
这种策略对**脆弱的部分**尤其有用：认证、支付处理、数据迁移——任何一个小错误都可能导致大范围故障的地方。这是一种预防性的调试手段。
### 性能优化检查
如果你的应用功能正常，但**很慢**或占用大量资源，你可以通过提示让 AI 帮你分析性能。这可能包括检查数据获取模式、查找渲染中的低效部分，或提出优化建议（缓存、memoization 等）。就像是在问：“我们怎样才能让它更快、更流畅？”
**示例提示 – 性能审计：**
```
我们的应用功能正常，但似乎**运行缓慢**。请**分析项目中的性能瓶颈**并提出优化建议：
- 检查是否存在不必要的数据库或网络调用（例如重复获取数据或 N+1 查询模式）。
- 识别可能过于频繁重新渲染或在主线程上执行繁重操作的组件。
- 检查我们对资源（图片、脚本）的使用情况：是否存在影响加载时间的大型资源包或未优化的资源？
- 提出改进建议，例如缓存常用数据、在适当位置使用 React memo 或懒加载，以及其他可以提升应用速度的方法。
请以列表形式提供分析和建议。暂时不要修改代码——只需告诉我们需要改进哪些方面以获得更好的性能。
```
在 Chat mode 中运行这段内容会给你一份诊断报告。AI 可能会这样说：
* *“Data fetching:* `ProjectList` 组件在每次渲染时都会获取数据。可以通过使用缓存，或将数据获取逻辑提到更高层级的上下文中来优化，这样就不会出现不必要的重复请求。考虑使用 state 或 context 在数据获取后存储项目数据。
* *Re-renders:* `TaskItem` 组件没有进行 memo 化，只要任意父级 state 发生变化，它就会重新渲染。如果任务很多，这会让交互变慢。建议：对 `TaskItem` 使用 `React.memo`，以避免不必要的重复渲染。
* *Assets:* 注意到有一个 2MB 的图像（logo）。这相当大；可以压缩或使用更低分辨率的图像来加快加载速度。
* *Bundle size:* 所有页面都被打包在同一个 bundle 中。可以考虑进行代码分割（对大型模块使用动态 `import()`），以加快初始加载。
* ...”\*
这些建议都基于常见的性能最佳实践。接下来你可以决定要落实哪些建议。你也可以向 Lovable 发出提示，让它应用其中之一：*“按照建议，使用 context 为项目数据实现缓存。”* 通过解决这些问题，你可以改善用户体验，并有可能降低成本（更少的调用、更少的计算）。
### 处理持续存在的错误
如果遇到那些怎么都消不掉，或者总是换个形式又出现的错误怎么办？如果没有解决真正的根本原因，就会发生这种情况。比如，你修好了某个问题，但底层问题又以一个新错误的形式在别处冒出来。这里有一套应对策略：
* **先问问 AI 已经尝试过什么。** 有时候在多次点击 Try to Fix 或手动输入提示之后，就不清楚到底改了什么。可以问：\_“到目前为止，我们为这个错误尝试了哪些解决方案？”\_。AI 会列出尝试过的方法，帮助你避免重复同样的修复。
* **让 AI 用简单的方式解释这个错误。** *“请用简单的方式解释一下这个错误为什么会发生。”* 这样可以看出 AI（以及你）是否真的理解它，你也有可能在这里发现某个误解。
* **考虑换一种思路。** 问：\_“鉴于这个错误一直在发生，我们是否可以尝试用不同的方法来实现目标？”\_。AI 可能会提出一种不同的实现策略，从而绕开这个有问题的区域。
* **回滚并重来。** 在最糟糕的情况下，你可能需要回退几个步骤。Lovable 允许你恢复到旧版本，甚至可以编辑过去的消息并回滚，以采用不同的思路。然后用更小的改动逐步推进。
最后，如果某个特定组件已经“死掉”（完全不工作，无论怎么改都不行），就把它隔离出来。通过提示创建一个该组件全新的极简版本，先看看是否能正常工作，然后再慢慢把它整合回你的项目中。这有点像“关掉再开机”，只是换成了代码形式——有时候从头重建这部分，比试图修补一个已经问题很严重的版本要容易得多。
在这一切过程中，别忘了和 AI 保持对话。把它当作协作者看待：*“我们修好了 X，但现在 Y 又出了问题。X 和 Y 之间有什么关系？这次修复会不会引发 Y 的问题？”* AI 可能会发现一些你之前没有注意到的关联。
## 调试流程示例
为了加深理解，我们通过两个常见的调试场景及其示例流程来演练一下：
### “卡在错误循环中”
你给了一个很复杂的提示，现在应用无法构建，而且 Try to Fix 已经连续失败了两次。
*流程：*
在整个过程中，你都先把错误描述清楚，并让 AI 确认它的理解，而不是盲目地一遍遍点击 Try to Fix。
### 「功能没按预期工作」
你添加了一个通知功能，但邮件没有发送。
*流程：*
本质上，通过描述你期望发生的事情（收到一封邮件）和实际发生的情况（什么都没发生，再加上一段日志），AI 就能够引导你完成整个排查过程。
### “UI 元素消失了。”
你重构了某些东西，现在整个 UI 的一个部分完全不见了（一个“失效组件”）。
*流程：*
或许它发现重构时把父级 JSX 里的 `ProjectList` 删掉了。它会建议重新导入并把它加回去。或者，父级中的 state 变化导致这个列表现在被无意中过滤掉了。
Aha\\\！于是你给出提示，\_“在 Dashboard 页面 JSX 中恢复 \_``*（它被意外删除了）。”* 问题解决。
在这个流程中，关键是注意到组件完全消失了，并把这一点表达清楚。AI 帮助你精确定位\_原因\_（是根本没被渲染，还是渲染了但为空，等等）。
使用 DevTools 和控制台日志
```
我的应用现在不工作了，屏幕是一片空白。
这是我从 DevTools 控制台复制/粘贴的内容，你能帮我修复这个问题吗？
Error occurred:
TypeError: Q9() is undefined at https://example.lovable.app/assets/index-DWQbrtrQQj.js
: 435 : 39117 index-DWQbrtrQQj.js:435:35112
onerror https://example.lovable.app/assets/index-DWQbrtrQQj.js:435
```
在所有这些场景中，*沟通和渐进式排查* 都是你的好帮手。利用 AI 在回忆细节（例如它之前做过什么）以及分析日志或错误方面的优势。也发挥你的优势来引导整个过程——你理解高层目标，并能决定什么时候该换个角度尝试。
## 根本原因分析、回滚与渐进增强
最后给你几点建议：
### 根本原因 vs. 症状
不要只问“现在该怎么办？”，而要始终问“为什么会发生这种情况？”。AI 可以帮你找出问题的根本原因，这样一旦修复，就能真正长久生效。比如，AI 的快速修复也许能让某个错误不再报出，但并没有解决背后的逻辑缺陷。如果你有这种怀疑，就要继续深挖：
*我看到你通过添加检查修复了空指针错误，但它一开始为什么会是 null 呢？我们能不能从根源上解决？*
这样才能得到更健壮的解决方案。
### **明智地回滚：**
Lovable 允许你回滚到之前的版本。如果代码因为一连串糟糕的修复变得过于混乱，不要犹豫使用这个功能。通常，回滚并尝试另一种方法会更快。如果你确实进行了回滚，一定要告诉 AI 你在做什么（这样它就不会因为代码突然变得不一样而困惑）。例如：
*我把项目回滚到了添加通知功能之前。我们再实现一次，这次更仔细一些。*
这样，AI 就能明白我们撤销了一些更改，正在再试一次。
### **渐进增强：**
在添加新功能（尤其是复杂功能）时，采用小而可测试的迭代来实现。 这不仅仅是一个提示编写技巧——它是一种非常适合与 AI 搭配的开发理念。 如果某个地方出错，你能准确知道是哪个小步骤导致的。你可以通过一次次提示来增强应用，这也意味着你可以通过一次次提示在相对独立的上下文中进行调试。 如果你发现自己在写一大段同时包含多个功能改动的提示，考虑把它拆分成多个提示词。 当你需要排查问题时，你会感谢现在的自己。
1. 添加失败的测试用例。
2. 隔离问题并分析依赖关系。
3. 在应用修复前先记录调查结果。
```
这是失败时的控制台日志。请分析该测试用例，排查认证流程中的错误，在理清依赖关系后给出解决方案。
```
### **边做边记录：**
在处理问题时及时记笔记会很有帮助（甚至可以在一次会话结束后让 AI 总结刚刚完成的内容）。这有点类似反向的元提示（meta prompting）——它会为你的修复过程建立一份历史记录。比如，在解决了一个棘手的 bug 之后，你可以向 AI 提示：
*Summarize what the issue was and how we fixed it.*
AI 的总结可以保存到 `README` 或日志中。这样未来的你，或者项目中的其他任何人，都能更容易理解当时发生了什么以及你们是如何解决问题的。
### **知道什么时候该寻求人类帮助：**
有时候，即使你已经尽力了，依然可能会卡住（也许是 Lovable 平台中的真正 bug，或者是超出你/AI 控制范围的事情）。Lovable 社区和客户支持就是为你而存在的。不要不好意思在他们的 Discord 或论坛上提问。很多时候，别人也遇到过类似的问题。先尽量通过 AI 收集尽可能多的信息（方便你提供具体细节），如果仍然需要帮助，再向社区求助。
这本指南最初是在我们的社区 Discord 服务器中分享的——在调试你的项目时可能会对你有所帮助：
在修复错误时，只专注于相关的代码部分，不要修改其他运行正常的部分。先分析报错信息并追踪到其根源。实施有针对性的修复，在解决具体问题的同时，确保与现有代码库保持兼容。在确认任何解决方案之前，一定要验证它既能解决最初的问题，又不会引入新的缺陷。始终保留已有的正常功能，避免重写与该错误没有直接关系的代码。
在修改现有代码时，应采用“外科手术式”的方式，只变更为实现所请求功能或修复所必需的部分。保留代码库中已有的变量命名、编码模式和架构决策。在提出修改建议前，先分析依赖关系，确保变更不会破坏现有功能。以最小差异（diff）的形式呈现改动，而不是完全重写代码。如果发现超出当前任务范围的改进点，请单独提出改进建议，但不要自动实现这些改动。
在建议新的数据库结构之前，先彻底检查现有架构，识别已经存在的表、关系和字段。尽可能复用现有表，而不是重复或复制数据模型。当确实需要修改数据库时，确保这些修改与现有查询和数据访问模式兼容。针对架构变更提前考虑迁移策略，以便保留现有数据。在提出任何变更之前，一定要验证外键关系和数据完整性约束。
以全面的诊断流程来处理每一个问题。首先通过仔细检查错误信息、日志和系统行为，收集所有相关信息。针对可能的原因提出多个假设，而不是草率下结论。以系统化的方式逐一验证每个假设，直到找出根本原因。在提出解决方案之前，先记录你的分析过程和结论。考虑潜在的边界情况以及它们可能对系统产生的影响。
在确认任何解决方案之前，先执行严格的验证流程。针对最初的问题测试该解决方案，确认它确实解决了问题。检查相关功能中是否出现了意料之外的副作用。确保性能不会受到不良影响。验证它在不同环境和配置下的兼容性。覆盖各种边界情况以确保健壮性。只有在完成这些验证之后，你才应该将该解决方案作为已确认的方案对外提交。
在风格、模式和实现方式上保持与现有代码库的一致性。先分析代码，找出命名约定、格式偏好和架构模式。在实现新功能或修复问题时，遵循这些既有模式。使用与项目中一致的错误处理策略、日志方式和测试方法。这样既能保持代码的可读性和可维护性，又能降低开发者的心智负担。
在添加新功能时，应在现有架构之上进行扩展，而不是引入完全全新的范式。先识别当前设计中的扩展点，并在此基础上实现新功能。确保改动与代码库中既有的模式和原则保持一致。关注向后兼容性，确保现有功能依然按预期运行。记录新功能如何与现有系统集成并对其进行扩展。
为所有更改和建议提供清晰、简明的说明。不仅要解释做了哪些更改，还要说明为什么这些更改是必要的，以及它们是如何工作的。记录解决方案中涉及的任何假设或依赖关系。在引入复杂逻辑或不明显的解决方案时代码中添加注释。当提出架构层面的变更建议时，提供图示或高层次说明，帮助你直观理解这些变更带来的影响。
识别何时某些解决方案可能引入技术债务，并对这些取舍保持透明。当时间限制需要采用不够理想的解决方案时，要清楚指出哪些部分有待在未来进行重构。区分快速修复与完善的解决方案，并根据具体情境推荐合适的做法。当技术债务无法避免时，要将其清晰记录下来，以便日后改进。
持续适应该项目的特定模式和偏好。注意对之前建议的反馈，并将这些经验融入后续的推荐中。在脑海中建立对应用架构的心智模型，并让它随着时间不断变得更加准确。记住以往的问题和解决方案，避免重蹈覆辙。主动理解支撑技术决策的底层业务需求。
在创建新的页面、组件或流程之前，先对代码库中现有的元素做一次全面盘点。使用相关关键词和文件名/路径模式搜索类似功能。尽量寻找复用或扩展现有组件的机会，而不是重新创建一套。已有相似功能时，先分析它们，判断是否可以通过参数化或改造来满足需求，而不是简单复制。始终在脑中保持对应用结构的整体模型，以便识别某个方案何时可能引入冗余元素。当需要类似的页面或流程时，考虑创建抽象组件，使其可以通过不同的数据或配置来复用，从而践行 DRY（Don’t Repeat Yourself，不要自我重复）原则。
主动识别并移除未使用的代码，而不是任由其不断累积。在替换功能时，要彻底移除旧实现，而不是仅仅将其注释掉，或与新代码并列保留。在删除代码之前，通过检查其导入和引用，验证它在整个应用中的使用情况；在可用的情况下，使用依赖分析等工具确认代码确实未被使用。在重构时，追踪已弃用的方法，并确保在不再被引用后将其正确移除。定期扫描孤立组件、未使用的导入、被注释掉的代码块以及不可达的条件分支。在建议移除代码时，清楚说明为何认为它是死代码，并在删除前确认不存在隐含的依赖关系。通过优先消除不再被执行的代码路径，来保持代码库的整洁。
将已正常工作的功能视为锁定系统，修改它们需要明确许可。在对任何运行正常的组件提出修改建议之前，先清晰识别其边界和依赖关系。没有明确指示时，绝不要移除或大幅更改当前正常运行的功能。当某个区域出现错误时，避免为了“以防万一”而去更改其他不相关且工作正常的组件。始终清楚了解应用中哪些部分是稳定的，哪些仍在开发中。采用以功能为中心的方法，将变更限定在特定的功能集内，避免影响到其他功能。在修改被多个功能共享使用的组件时，要确保所有依赖这些组件的功能依然按预期工作。通过在修改前彻底记录各功能间的依赖关系，为可能受到影响的功能建立保护措施。在对应用中既有且可正常工作的部分提出修改建议前，一定要明确确认对这些部分进行修改的意图。
在遇到复杂错误时，不要在尚未深入理解之前就急于套用修复方案。先有意识地退一步，从多个角度审视问题，再提出解决思路。多考虑在思路上截然不同的方案，而不是同一策略的细微变体。在推荐具体做法之前，至少记录三种可能的解决方案，并分别列出它们的优点和缺点。主动质疑对错误成因的初始假设，尤其是在常规修复方法不起作用的时候。也要考虑一些非常规的问题来源，比如环境配置、外部依赖，或者一时难以察觉的竞态条件。尝试反向思考：不要只问“why isn’t this working?”，而要问“under what conditions would this behavior actually make sense?”。把复杂问题拆解成可以独立验证的更小组件。当错误来源仍不清晰时，实施有针对性的调试策略，比如增加日志、设置断点或进行状态跟踪，以收集更多信息。在处理特别晦涩的问题时，要乐于提出实验性的修复方案，把它们视为学习机会，而不是一锤定音的最终解决办法。
在提出任何数据库查询或架构修改建议之前，务必先确认数据库的当前状态。检查现有的表、字段和关系，确保你不会建议创建已经存在的元素。在建议查询时，先查看代码库中是否已有类似查询可以复用或改造。审查现有的数据模型、迁移文件和架构（schema）定义，以建立对数据库结构的准确理解。对于任何关于创建新表的建议，要明确确认该表目前不存在，并解释为何需要创建新表，而不是修改现有表。在建议新增字段时，要核实是否已有功能相同但名称不同的字段在使用。考虑所建议查询对数据库性能的影响，在合适的情况下提供优化后的替代方案。始终在现有数据库架构的上下文中提出查询建议，而不是将它们视为孤立的操作。
在整个应用中严格遵循既定的设计系统和配色方案。在创建新的 UI 组件之前，先仔细研究现有组件，以理解其视觉语言、间距模式、交互模型和主题方案。在实现新界面时，应复用现有的组件模式，而不是创建新的视觉变体。从现有代码库中提取颜色值、排版、间距和其他设计 token，而不是引入新的数值。确保在所有组件中一致地处理各类状态（hover、active、disabled、error 等）。在实现新布局时，遵循既定的响应式行为模式。在提出 UI 改进建议时，要确保这些改进是提升而非破坏应用整体视觉一致性。在所有组件中始终如一地执行无障碍标准，包括颜色对比度、键盘导航和屏幕阅读器支持。为任何组件变体及其适用场景和使用方式编写文档，以便实现一致的应用。在引入新的视觉元素时，要清楚展示它们如何与现有设计系统集成并形成互补，而不是与之割裂开来。
在遇到错误时，应采用科学的调试方法，而不是随意修改代码。首先在可控环境中精确复现问题。收集完整的数据，包括控制台日志、网络请求、组件状态和错误信息。针对可能的原因提出多个假设，并系统地逐一验证。通过缩小受影响的组件范围并识别触发条件来定位问题。将你的调试过程和结论记录下来，整理成文档，方便今后参考。使用合适的调试工具，包括浏览器开发者工具、React DevTools，以及代码级调试技术。始终确认你的解决方案能够彻底解决问题，并且不会在应用的其他部分引入新的问题或回归。
在实现任何功能之前，先深入分析数据库 schema 和 TypeScript 接口中的类型定义。在整个代码库中保持严格的类型检查，避免将 `any` 类型当作偷懒的手段。处理数据转换时，要在流水线的每个步骤验证类型安全。特别留意常见的类型不匹配问题，例如数据库中的数字以字符串形式传入、日期解析需求，以及可空字段的处理。在数据库列和 TypeScript 接口之间保持一致的命名规范。为复杂的类型关系和特殊处理要求编写文档。使用真实的数据结构进行测试，并验证各种边界情况，尤其是对 null/undefined 的处理。当出现错误时，回溯数据转换流水线，精确定位类型出现不一致的位置，并给出在保持类型安全前提下的修复建议。
将数据流视为一条从数据库，经由 API 和状态层一直到 UI 的完整流水线。在实现功能时，仔细追踪数据在每个阶段是如何被转换的。实现合适的查询失效策略（query invalidation），以确保 UI 始终与数据库状态保持同步。在关键节点添加有针对性的控制台日志（console logs），以监控数据的变化过程。为「数据应在何时、以何种方式响应操作进行更新」建立清晰的心智模型。特别注意缓存策略以及潜在的陈旧数据问题。在调试数据流问题时，要有步骤地从数据源一路跟踪到最终目的地。检查时序问题、竞争条件（race conditions）和转换错误。验证到达各组件的最终数据结构是否与组件预期一致。实现健壮的错误边界和加载状态管理，以在数据流发生中断时保持 UI 的稳定性。
主动监控应用性能，而不是等到问题变得严重才处理。审查查询缓存策略，以尽量减少不必要的数据库调用。通过合理使用 memoization 和依赖管理，检查并消除不必要的组件重复渲染。分析数据获取模式，排查潜在的 N+1 查询问题、过多的瀑布式请求或冗余请求。对长列表实现虚拟化，并对大型数据集进行分页。通过代码分割和懒加载来优化 bundle 体积。压缩并优化包括图片在内的各类静态资源。使用合适的性能分析工具识别瓶颈，例如 React DevTools、Performance 面板、Network 面板和 Memory 分析器。将优化重点放在直接影响用户体验的指标上，例如加载时间、可交互时间以及 UI 响应速度。实施有针对性的性能优化，而不是进行过早优化。
实现一套全面的错误处理策略，在保持应用稳定性的同时提供有意义的反馈。针对潜在问题代码段有策略地使用 try/catch 块。在应用中创建分层的错误边界，将故障限制在特定组件内，而不是让整个应用崩溃。设计良好的优雅降级模式，使组件在数据受限的情况下仍能继续运行。提供清晰、友好的错误消息，用非技术化的语言解释问题。实现包含重试逻辑、后备方案和状态重置在内的恢复机制。维护健壮的错误日志记录，在尊重隐私的前提下捕获足够的调试上下文。对各种错误场景进行充分测试，确保恢复机制按预期工作。在给出解决方案时，确保它们解决的是根本原因，而不仅仅是掩盖表面症状，并验证它们在所有相关环境和边缘情况中都能正常工作。
在进行组件设计时，要清晰理解组件的层级结构和职责分工。将组件想象成具有正确父子关系的家谱树。通过在合适的场景下策略性地使用 context 或状态管理，尽量减少 prop 的层层向下传递（prop drilling）。在容器（智能）组件和展示（哑）组件之间建立清晰的边界。为组件之间的通信（包括父子交互和兄弟组件交互）建立一致的模式。在调试组件问题时，分析完整的组件树、prop 传递路径、状态所在层级以及事件处理函数的连接情况。以单一职责和清晰接口来设计组件。为组件关系和依赖关系编写文档，以便于后续维护。在适当的地方实施性能优化，包括 memoization、懒加载和代码分割。保持组件可复用性与专用性之间的平衡，既避免重复实现，也避免过度抽象。
在集成 API 时，需要从请求、响应到错误处理制定完善的整体策略。检查每个请求的认证头信息（header）、参数以及 body 格式是否正确。为所有网络操作实现健壮的错误处理机制，并针对不同错误类型进行单独捕获。确保请求负载、预期响应与应用状态之间的类型保持一致。配置合适的 CORS 设置，并验证它们在所有环境中都能正常工作。针对瞬时故障实现智能重试机制，并采用指数退避策略。考虑速率限制的影响并实现合适的限流机制。添加有策略的请求缓存，以提升性能并减少服务器负载。监控网络性能，包括请求耗时和载荷大小。针对正常路径（happy path）和各种失败场景测试 API 集成。为所有 API 端点维护清晰的文档，包括其用途、预期参数和响应格式，以便于后续开发和调试。