FrontEnd Interview

Appearance

需求分析三要素：技术落地前的“三维CT扫描” ​

如果把项目开发比作一场航海，需求分析 就是确定“目的地”和“航线”的过程。很多项目之所以半路搁浅，不是技术不够强，而是出发前没搞清楚“要去哪里”——就像船开了一半，才发现目的地是湖泊，却驾着一艘远洋巨轮。

需求分析不是“用户要什么就记什么”，而是要提炼出决定技术方向的核心要素。经过行业验证，业务场景、性能要求、用户规模 这三个要素，构成了需求分析的“铁三角”。它们相互关联，共同决定了“用什么技术”和“怎么实现”。今天我们就逐一拆解，看看这三个要素如何影响技术决策。

一、业务场景：技术的“应用舞台”，决定“做什么” ​

什么是业务场景？ ​

业务场景是指“用户在什么情况下使用系统，完成什么任务，达到什么目标”。它不是孤立的功能点，而是包含流程、角色、规则的完整故事 。比如“外卖下单”不是一个场景，“用户在下班路上打开APP，选择3公里内的餐馆，用优惠券支付，要求30分钟内送达”才是完整场景。

为什么业务场景是核心？ ​

技术就像工具：锤子适合敲钉子，螺丝刀适合拧螺丝，脱离场景谈工具没有意义。同样，一个系统的技术选型，首先要服从业务场景的“剧情需要”。

案例：不同业务场景的技术差异 ​

  • 场景A：电商订单系统
    核心流程：下单→支付→扣库存→发货→售后。
    关键规则：库存不能超卖、支付和扣库存必须同时成功或失败（事务一致性）、订单状态要随流程实时更新。
    适合技术：Java（强类型、事务支持好）+ MySQL（支持事务）+ Redis（库存预扣减，防止超卖）。

  • 场景B：短视频推荐系统
    核心流程：用户刷视频→系统记录行为（点赞/划走）→实时更新推荐模型→推送下一个视频。
    关键规则：推荐延迟要低（否则用户划走了还没算完）、需处理海量行为数据、模型要高频迭代。
    适合技术：Python（机器学习库丰富）+ Kafka（高吞吐，收集行为数据）+ Spark（实时计算）+ 推荐算法框架（如TensorFlow）。

代码示例：业务场景决定数据模型设计 ​

同样是“用户行为记录”，不同场景的数据模型天差地别：

电商订单场景的“用户行为”（关注事务和状态）

sql
-- 订单相关的用户行为表（需记录状态和关联订单）
CREATE TABLE user_order_actions (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL, -- 用户ID
  order_id BIGINT NOT NULL, -- 关联的订单（核心，因为行为和订单强绑定）
  action_type VARCHAR(20) NOT NULL, -- 行为类型：支付/取消/确认收货
  action_time DATETIME NOT NULL, -- 行为时间（精确到秒，用于追溯状态）
  status VARCHAR(20) NOT NULL, -- 行为结果：成功/失败（比如支付失败）
  transaction_id VARCHAR(50), -- 支付流水号（和财务对账用）
  INDEX idx_order (order_id) -- 按订单查询行为，高频需求
);

短视频场景的“用户行为”（关注海量和实时）

sql
-- 短视频用户行为表（需高效写入和按用户查询）
CREATE TABLE user_video_actions (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  user_id BIGINT NOT NULL, -- 用户ID
  video_id BIGINT NOT NULL, -- 视频ID
  action_type VARCHAR(10) NOT NULL, -- 行为类型：点赞/划走/评论（简单分类）
  action_time BIGINT NOT NULL, -- 行为时间（用时间戳，方便计算间隔）
  duration INT, -- 观看时长（短视频核心指标，电商场景几乎不用）
  INDEX idx_user_time (user_id, action_time) -- 按用户+时间范围查询，用于推荐模型
) ENGINE=MyISAM; -- 用MyISAM而非InnoDB，因为写入频繁，无需事务支持

业务场景的本质是“定义问题边界”：搞清楚用户在系统里“演什么戏”，技术才能“搭对舞台”。

二、性能要求：技术的“速度表”，决定“跑多快” ​

什么是性能要求？ ​

性能要求是“系统在特定场景下必须达到的运行指标”，比如：

  • 接口响应时间（用户点提交后，多久能看到结果）；
  • 并发处理能力（同时有多少用户操作，系统不卡顿）；
  • 数据吞吐量（每天能处理多少订单/消息/请求）。

这些指标不是“越快越好”，而是“刚好满足业务需要”——就像汽车时速，城市通勤不需要300km/h，高速行驶不能低于60km/h。

为什么性能要求不能含糊？ ​

性能是用户体验的“隐形杀手”：研究显示，网页加载超过3秒，53%的用户会放弃；APP操作响应延迟超过1秒，用户满意度下降40%。更关键的是，性能问题往往“早不解决，晚解决不了”——初期设计没考虑高并发，后期想优化可能需要重构整个架构。

案例：不同性能要求的技术实现 ​

  • 低性能要求（内部OA系统）：
    每天活跃用户100人，最多10人同时操作，响应时间1-2秒用户能接受。
    技术选择：PHP（开发快）+ 单台服务器 + 普通MySQL配置。

  • 高性能要求（春运12306抢票）：
    峰值并发用户超1亿，单秒订单提交量超10万，响应延迟不能超过500ms。
    技术选择：分布式架构 + 多级缓存（本地缓存+Redis集群）+ 消息队列（削峰）+ 分库分表。

代码示例：性能要求决定接口设计 ​

同样是“查询商品列表”，不同性能要求的实现差异：

低性能要求（内部商品管理系统）

java
// 直接查数据库，不做缓存（用户少，无所谓）
@GetMapping("/products")
public List<Product> getProducts() {
  // 简单查询，甚至可能没加索引
  return productMapper.findAll(); 
}

高性能要求（电商首页商品列表）

java
@GetMapping("/products")
public List<Product> getProducts() {
  // 1. 先查Redis缓存（内存查询，速度比数据库快100倍+）
  String cacheKey = "products:list";
  String cacheValue = redisTemplate.opsForValue().get(cacheKey);
  if (cacheValue != null) {
    return JSON.parseArray(cacheValue, Product.class); // 直接返回缓存
  }
  
  // 2. 缓存没命中，查数据库（加了索引，优化查询语句）
  List<Product> products = productMapper.findWithIndex(); 
  
  // 3. 结果写入缓存（设置过期时间，避免数据过时）
  redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(products), 5, TimeUnit.MINUTES);
  
  return products;
}

性能要求的本质是“定义系统的能力上限”：就像给汽车限速，既要保证跑得动，又不能因“超速”（过度优化）浪费成本。

三、用户规模：技术的“承重极限”，决定“能装多少人” ​

什么是用户规模？ ​

用户规模是“系统需要服务的用户数量及增长预期”，核心指标包括：

  • 日活跃用户数（DAU）：每天有多少用户用系统；
  • 峰值并发用户数：某一时刻同时操作的最大用户量（比如早8点的通勤APP）；
  • 用户增长曲线：未来6个月/1年可能达到多少用户（比如新产品预计从1万DAU涨到100万）。

用户规模就像“建筑的承重设计”：小茶馆不需要考虑抗震等级，摩天大楼必须能抗8级地震。

为什么用户规模影响架构？ ​

用户规模决定了系统的“扩展能力”：

  • 100个用户：单台服务器+单数据库足够；
  • 10万用户：需要多台服务器负载均衡+数据库读写分离；
  • 1000万用户：必须用分布式架构+分库分表+CDN加速。

如果初期按“小用户”设计，后期用户爆发增长，就会像“用自行车载10个人”——必然崩溃。

案例：用户规模驱动的架构演进 ​

某社交APP的架构变化：

  • 阶段1（1万DAU）：单台云服务器（2核4G）+ 单库MySQL，成本低，维护简单。
  • 阶段2（10万DAU）：加一台应用服务器（负载均衡），数据库拆成“主库（写）+从库（读）”，避免读写冲突。
  • 阶段3（100万DAU）：应用服务器扩到10台（用K8s管理），数据库分库分表（按用户ID拆分，避免单表数据量过大），加Redis缓存热点数据。

每一步演进，都是用户规模“倒逼”技术升级。

代码示例：用户规模决定数据存储设计 ​

同样是“存储用户信息”，不同用户规模的表设计差异：

小用户规模（1万用户）

sql
-- 单表存储所有用户，简单直接
CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  username VARCHAR(50) UNIQUE,
  password VARCHAR(100),
  nickname VARCHAR(50),
  avatar VARCHAR(200),
  register_time DATETIME
);
-- 数据量小（1万条），查询再慢也能接受

大用户规模（1000万用户）

sql
-- 分表存储：按用户ID取模拆分到10张表（users_0到users_9）
-- 例：用户ID=123 → 123%10=3 → 存在users_3表
CREATE TABLE users_0 (
  id BIGINT PRIMARY KEY, -- 用全局ID生成器，不依赖自增（避免分表ID冲突）
  username VARCHAR(50) UNIQUE,
  password VARCHAR(100),
  nickname VARCHAR(50),
  avatar VARCHAR(200),
  register_time DATETIME,
  INDEX idx_username (username)
) ENGINE=InnoDB;

-- 代码层面需要路由到对应表（Java示例）
public User getUserById(Long userId) {
  int tableIndex = (int) (userId % 10); // 计算分表索引
  String tableName = "users_" + tableIndex;
  return userMapper.selectById(tableName, userId); // 查对应表
}

分表的目的是避免“单表数据量过大”：MySQL单表超过1000万条，查询速度会明显下降，就像“一本书厚到1000页，找某一页自然慢”。

用户规模的本质是“定义系统的扩展边界”：提前预判用户增长，才能让技术架构“随需而变”，而不是“被迫重构”。

总结：三要素的“协同效应” ​

业务场景、性能要求、用户规模不是孤立的，它们像“三维坐标”，共同定位需求的“真实模样”：

  • 业务场景决定“技术做什么”，是方向；
  • 性能要求决定“技术要多快”，是速度；
  • 用户规模决定“技术能装多少”，是容量。

比如“直播带货”场景：

  • 业务场景（主播开播→用户观看/下单→实时互动）决定需要“低延迟音视频传输+实时消息系统”；
  • 性能要求（单场直播10万人同时观看，评论延迟<1秒）决定需要“CDN加速+高并发消息队列”；
  • 用户规模（日常100场直播，每场峰值10万观看）决定需要“分布式部署+弹性扩容”。

只有把这三个要素分析清楚，技术选型才能“有的放矢”——否则，就像蒙眼射箭，射中靶心全靠运气。

需求分析的终极目标，不是写出完美的文档，而是让技术团队回答一个问题：“我们到底要造一艘什么样的船，去什么样的海？” 想清楚这个问题，后面的技术决策就会水到渠成。