做前端两三年之后，很多人会撞上同一堵墙：单页面写得很熟，组件也能拆，但一让你从零搭一个「能长大」的项目，心里就发虚。接口层怎么分层、状态放哪儿、目录怎么切、加一个新功能会不会牵一发动全身——这些问题在纯粹的页面练习里永远练不到。这门课选的是「当当书城 WebApp」这个具体场景，要解决的就是这堵墙。

它盯上的三个能力缺口

第一是架构判断力。会写组件不等于会组织代码。书城这类应用天然有首页、分类、搜索、详情、购物车、个人中心等多条业务线，模块之间横着数据、竖着依赖。什么该抽成公共层、什么该就地内聚，靠的是对「未来会怎么改」的预判，而不是当下的顺手。

第二是数据流的可控性。书城类应用的特点是列表多、分页多、筛选条件多，同一个页面可能同时依赖路由参数、本地缓存和远端数据。如果没有清晰的数据流向设计，很快就会写出「改一个筛选条件，购物车数字跟着抽风」的代码。

第三是前后端的衔接意识。课程定位是全栈，意味着你不仅要知道前端怎么调接口，还要理解接口该怎么设计、字段怎么定、异常怎么返回。只看前端视角的人，往往在联调阶段才发现自己这边的抽象根本接不住后端的真实结构。

用书城这个题材练什么

电商类是检验架构的经典题材，因为它把几类难点都凑齐了：

列表与详情的状态复用——同一份数据在不同视图里的缓存与更新策略；
购物车这种「跨页面共享且需要持久化」的状态，放在哪儿最不容易失控；
搜索与分类带来的路由参数变化，如何避免重复请求和状态残留；
页面级懒加载与模块边界，怎样让新增一个业务模块不触碰旧代码。

这些点单拎出来都不新鲜，难的是在同一个项目里同时成立。课程的价值就在于把这些决策放在一条完整的业务链上做，而不是拆成孤立的知识点讲。

看的时候该怎么动手

这类实战课最容易变成「视频看完就忘」。建议按下面的节奏走：

先自己画一遍目录结构。在看到他动手之前，先想清楚如果是你来切，会怎么分模块，再对比差异在哪，这个差异就是你要补的认知。
把接口层当成重点。请求封装、错误处理、加载态管理这几块，不要照抄，试着换一种写法重写一遍，看能不能撑住同样的业务。
故意加需求。比如加一个「浏览历史」或者「优惠券」，看现有架构要改几个文件。改得越少，说明你前面的抽象做对了；改得越多，就回头看看哪一层漏了。
留一份自己的决策记录。哪个状态用了全局、为什么，哪个地方宁可重复也不抽象，写下来。面试和自我复盘时，这比「我做过一个电商项目」有用得多。

看完应该能回答的问题

用它做一次自测，如果下面几条你都能给出自己的答案，说明这门课没白看：

这个项目里，哪些状态是全局的，哪些是页面级的？边界是按什么划的？
如果我明天要接入真实的商品接口，需要改动的地方集中在哪里？
购物车的数量徽标和购物车页面，数据是怎么保持一致的？有没有可能不同步？
新增一个业务模块，最少要动几个目录？为什么会这么少（或多）？
如果这个应用从书城换成生鲜，架构里哪些部分可以原样搬走？

能答上三四个，说明你摸到了可扩展性这件事的门道；一个都答不上，那就别急着翻下一篇，回去把对应章节重看一遍再动手写。缺什么补什么，这门课适合当镜子用，照出你在架构层面还空着的那块。