害怕系统设计？试试这个权衡象限

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

我是一名前端工程师。

我至今仍记得第一次有人让我“设计一个可扩展的系统”时的情景。

我愣住了。

没有文档，没有明确的起点，只有一句模糊的提示和一块空白的白板。

最终，我放弃了，我说：“我觉得我做不到。”

并非我不会建造东西——我只是不懂得如何用系统设计的思维方式思考。哪些事情应该优先考虑？哪些事情需要权衡取舍？哪些事情才是真正重要的？

随着时间的推移，通过面试、项目以及很多次慌乱地在谷歌上搜索答案的时刻，我开始注意到自己解决问题的方式存在某种模式。

我最终总是会记下同样的四种想法：我们要解决什么问题，我们如何构建它，可能会出现什么问题，以及如何扩展它。

所以我开始把它们放在一个简单的 2×2 象限里。

不是框架，也不是工具。

一件小事却让我感觉不那么束手无策——尤其是在面试期间。

这篇博客旨在分享这个象限图，以及你如何也能使用它——无论你是准备面试还是只是想更清晰地设计一些东西。

什么是权衡象限？

它就是一个2×2的网格。

就是这样。

每当我设计什么东西时——无论是新功能、可重用组件，还是准备面试——我都会在纸上或笔记中画一个大大的“+”，然后开始填充它。

每个象限都迫使我放慢速度，提出不同类型的问题：

我们要解决什么问题？ ——用户实际遇到的问题是什么？用户体验流程是什么？什么最重要？

我们将如何构建它？ ——我们需要哪些组件？哪种渲染策略最合适——CSR、SSR 还是 SSG？这是单体架构还是模块化架构？

可能出现什么问题？ ——如果 API 出现故障怎么办？如果数据丢失怎么办？在慢速设备或网络状况不佳的情况下会发生什么？

它如何扩展？ ——它能处理更多用户吗？它以后能支持版本控制或A/B测试吗？它的性能是否优化过？

重点不在于“完美”地填写，而在于将你的思考过程可视化。

最棒的是什么？无论你是设计整个页面还是单个下拉菜单，它都能正常工作。

让我们应用一下：设计产品列表页面 (PLP)

想象一下，你在一家电子商务公司工作，公司要求你设计产品列表页面 (PLP)的前端系统——就像你在亚马逊、Flipkart 或 Myntra 上看到的那些页面一样。

页面应该：

• 显示产品网格
• 允许按品牌、尺寸、价格等进行筛选。
• 支持排序（价格、人气、最新发布）
• 处理分页或无限滚动
• 要兼顾移动设备和桌面设备。
• 在高客流量的促销活动中效果显著
• 支持深度链接（URL反映筛选条件和排序方式）
• 可选择在行之间插入广告或赞助产品

哦，而且它还应该速度快、稳定性强、易于长期维护。

在深入了解组件或 API 调用之前，让我们应用权衡象限来更好地理解问题。

功能性需求和非功能性需求

一旦我们使用权衡象限明确了问题，下一步就是明确定义需求——包括功能性需求和非功能性需求。

这有助于防止范围蔓延，设定预期，并确保你的设计是针对真正重要的东西。

我也逐渐明白（有时是付出惨痛代价才明白的😅），认真思考哪些功能真正需要投入生产环境至关重要。功能可以随时添加，但系统设计的目标是合理安排优先级，而不是罗列所有可能的功能。

功能需求

v1 版本必备功能：

• 显示包含图片、标题和价格的产品网格。
• 允许按品牌、价格和类别等关键字段进行筛选
• 支持基本排序选项（例如，价格从低到高）
• 启用分页或无限滚动
• 在 URL 中反映筛选/排序状态（深度链接）
• 响应式布局，可在移动设备和桌面设备上流畅运行

锦上添花的功能（可在发布后添加）：

• 行间插入赞助广告
• 多选筛选器（例如，选择多个品牌）
• 清除所有筛选条件按钮
• 面包屑导航和类别元数据
• 预先获取下一页数据，实现更流畅的无限滚动

非功能性需求

生产必备条件：

• 对 API 调用进行防抖处理，以避免不必要的流量
• 优雅加载（骨架或旋转动画）
• 稳定布局 - 避免使用 CLS（尤其是有广告位的）
• API故障恢复能力（备用UI）
• 针对首页产品详情页 (PLP) 进行了搜索引擎优化 (SSR) 优化
• 键盘和屏幕阅读器辅助功能，支持筛选和排序

发布后改进：

• 用于收集筛选器使用情况、滚动深度和广告点击次数的遥测数据
• 资源和过滤器配置的 SWR/CDN 缓存
• 使用懒加载图像IntersectionObserver
• 产品卡片变体的A/B测试

产品列表页面的组件架构

既然我们知道了 PLP 需要做什么，让我们把它分解成各个组成部分。

其理念是保留物品：

• 模块化和可重复使用
• 尽可能采用配置驱动
• 可扩展以支持广告、A/B 测试和 SSR 等功能。

以下是对此的简要概述：

<PLPPage />
├── <FilterSidebar />           ← Brand, size, price filters
│   └── <FilterGroup />
│       ├── <CheckboxFilter />
│       └── <RangeSliderFilter />
├── <SortBar />                 ← Sort options (dropdown or pills)
├── <ProductList />             ← Displays product + ad rows
│   └── <ProductRow />
│       ├── <ProductCard />
│       └── <SponsoredCard />   ← Conditionally rendered
├── <PaginationControls />      ← Or <InfiniteScrollLoader />
├── <SkeletonLoader />          ← Loading state for list
├── <EmptyState />              ← No results found
└── <TelemetryTracker />        ← Fires scroll, ad impressions, clicks

这些组件中的每一个都在页面的功能和扩展方式中发挥着特定的作用。

让我们快速浏览一下，了解它们如何融入更大的格局。

产品列表页面的 API 设计

现在组件架构已经就位，下一步是设计能够清晰地驱动前端的 API。

我们的 API 应该：

• 跨领域工作（鞋类、家具、书籍、植物）
• 同时支持产品和赞助内容
• 采用配置驱动的方式，无需硬编码即可实现灵活性。

API设计背后的思考过程

API 不应该将前端逻辑与特定筛选条件（如品牌、尺寸、材质）耦合，而应该通过配置来驱动显示哪些筛选条件。

这样一来，筛选侧边栏就变成了动态的，同一个产品定位政策 (PLP) 就可以在不同的类别中使用，而无需或只需很少的硬编码逻辑。

我们还希望在产品列表中插入广告或赞助卡片——因此响应应包含各种类型的项目，每个项目都按其类型进行标记。

为了控制赞助卡片的显示位置，我们使用 slotIndex，这样前端就可以将卡片插入到该位置而无需猜测。

{
  "meta": {
    "total": 1870,
    "page": 3,
    "limit": 20,
    "hasMore": true
  },
  "filters": [
    {
      "type": "checkbox",
      "label": "Brand",
      "key": "brand",
      "options": ["Nike", "Puma", "Adidas"]
    },
    {
      "type": "range",
      "label": "Price",
      "key": "price",
      "min": 799,
      "max": 9999
    },
    {
      "type": "checkbox",
      "label": "Size",
      "key": "size",
      "options": ["6", "7", "8", "9", "10"]
    }
  ],
  "sortOptions": [
    { "label": "Popularity", "value": "popularity" },
    { "label": "Price: Low to High", "value": "price_asc" },
    { "label": "Newest First", "value": "newest" }
  ],
  "items": [
    {
      "type": "product",
      "slotIndex": 0,
      "data": {
        "id": "p123",
        "title": "Nike Air Max",
        "price": 3999,
        "image": "https://cdn/air-max.jpg",
        "rating": 4.5,
        "available": true,
        "badges": ["Best Seller"]
      }
    },
    {
      "type": "ad",
      "slotIndex": 1,
      "data": {
        "id": "ad789",
        "title": "Sponsored: Adidas Originals",
        "image": "https://cdn/ad.jpg",
        "ctaUrl": "https://yourstore.com/adidas-campaign",
        "trackingPixel": "https://track.adid.as/imp.png"
      }
    },
    ...
  ]
}

这种API设计为何有效

性能考量

一旦您的 API 和组件架构到位，下一个重要问题是：“这在现实世界中表现如何？”

产品列表页面在本地开发环境中可能运行良好，但在实际环境中（例如设备速度慢、3G 网络、高并发性），很快就会出现问题。

以下是我对PLP中绩效的看法：

分页和防抖动

• 始终对 API 调用进行防抖、过滤和排序，以避免网络拥塞。
• 对于无限滚动，请务必限制或锁定分页请求，以防止出现竞态条件。
• 在页面之间添加加载状态，以便提供反馈并避免重复加载。

虚拟化和延迟加载

• 使用虚拟化库（例如react-window或）react-virtualized仅渲染可见产品
• 使用延迟加载图片的IntersectionObserver方式，可以加快页面初始加载速度。
• 延迟加载广告素材（尤其是第三方跟踪像素）

骨架与感知表现

• 数据获取期间，显示加载骨架图而不是空白区域。
• 保持布局稳定性，预留广告空间以避免布局偏移（CLS）
• 预加载下一页数据，使无限滚动流畅无阻。

CDN、缓存和SWR

• 使用 SWR 或 localStorage 缓存静态过滤器配置和排序选项
• 使用 CDN 分发产品图片，并使用 WebP 或 AVIF 格式进行压缩。
• 应用stale-while-revalidate缓存策略，保持 PLP 响应迅速，避免内容过时。

遥测和监测

• 跟踪 API 响应时间、滚动深度、筛选器交互和广告点击情况
• 如果 API 故障率超过阈值，则设置前端警报。
• 使用这些指标来指导 A/B 测试和用户体验决策。

我会在面试中说的话

“在产品生命周期管理（PLP）中，性能不仅仅关乎速度，更关乎用户体验。框架、延迟加载和虚拟化技术能带来巨大的差异。我还会确保过滤器配置被缓存，广告不会阻塞主线程，并且所有 API 调用都经过防抖处理。”

最后想说的话

如果你曾经因为系统设计而不知所措，要知道——你并不孤单。

我制作这个象限图是因为我需要一些简单的东西来帮助我摆脱困境。

无论你是准备面试还是解决工作中的问题，我都希望这能帮助你放慢速度，提出更好的问题，并充满信心地进行设计。

如果这对你有帮助，请告诉我——或者分享你自己的象限图版本。我很想看看。🙂