Web 基础总结：从导航到可恢复交互
这一阶段把页面还原为浏览器实际执行的过程。HTML 提供结构和默认行为，CSS 决定内容怎样布局与绘制，JavaScript 接收事件并协调异步状态，TypeScript 检查代码内部的静态关系，Web API 则让页面访问网络、地址栏、存储、线程和性能数据。框架会重新组织这些能力，却不会替浏览器完成另一套规则。
一次导航怎样变成页面
用户访问 URL 后，浏览器先取得响应字节并解析 HTML。解析过程中会发现样式表、脚本、图片和其他资源；CSS 经过层叠、布局、绘制与合成影响最终像素；JavaScript 模块完成下载、链接和求值后，才能监听事件、发起请求并修改状态。状态变化投影到 DOM，浏览器随后安排新的渲染工作。
排查问题时通常沿相反方向走。像素异常先看计算样式、尺寸和覆盖关系；内容错误要比较 DOM、应用状态和原始数据；状态陈旧要检查事件顺序、请求取消和缓存；页面骨架已经错误时，则回到响应内容和 HTML 解析结果。
HTML：先保证任务本身成立
HTML 的价值不只在于生成 DOM。标题、landmark、链接、按钮、表单和表格会同时影响键盘操作、屏幕阅读器、搜索引擎和无脚本场景。浏览器还会修复不合法的嵌套，因此 DevTools 中的 DOM 可能不同于源文本。
设计页面时，先用原生元素表达用户动作，再加入脚本增强。提交表单、打开链接和阅读主要内容应尽量保留默认路径；自定义组件需要处理焦点、键盘、名称和状态，但不能只通过视觉样式模仿原生控件。若脚本或资源加载失败，用户仍应看到可理解的内容和下一步。
CSS：从层叠原因追到渲染成本
一条声明能否生效，要依次考虑来源、层、重要性、作用域、优先级和源码顺序。遇到样式冲突，查看浏览器给出的获胜规则比不断增加选择器更可靠。布局问题还需要明确包含块、格式化上下文、滚动容器和固有尺寸；移动端溢出经常来自内容最小尺寸或错误的滚动所有权，并非简单缺少媒体查询。
性能分析也应回到具体阶段。频繁改变几何属性可能触发布局和绘制，大面积滤镜或阴影会增加绘制成本，合成层过多又会消耗内存。先通过 Performance 和 Rendering 工具确认瓶颈，再决定是否减少 DOM、限制影响范围或调整动画属性。prefers-reduced-motion、高对比度和缩放下的可读性也属于正常设计条件。
JavaScript：明确执行顺序和状态所有者
同步代码运行在当前调用栈，Promise continuation 进入微任务队列，计时器、消息和许多事件则等待后续任务。微任务会在当前任务结束后集中清空，过长的同步工作或递归微任务都会推迟输入响应和绘制。理解这套顺序后，许多“偶尔发生”的界面错误都能还原为可复现的时间关系。
页面状态应有清楚的权威来源。可分享的筛选条件放在 URL，短暂的展开或提示留在内存，需要跨会话保留的偏好再进入存储。搜索结果、计数和选中项摘要通常从源状态计算，无须保存第二份副本。请求、订阅、Worker 和计时器都要跟随页面或组件生命周期取消和清理，旧响应也必须证明自己仍对应当前用户意图，才可以更新界面。
TypeScript：知道静态检查在哪里结束
TypeScript 能检查字段、联合类型、泛型和模块之间的关系，但编译后的 JavaScript 不会自动验证网络响应、存储记录或用户输入。外部数据在进入领域模型前仍应视为 unknown，通过解析器逐字段检查；失败结果要带上路径和原因，让界面与日志能够区分缺字段、类型错误和不支持的版本。
严格配置能暴露空值、索引访问和模块解析问题，却不能替代运行时授权，也不应通过层层断言把不确定性藏起来。类型声明、实际模块格式和宿主行为需要一致：代码通过类型检查，只说明静态关系成立，不保证资源一定可加载、接口一定可信或浏览器一定支持目标能力。
Web API：把权限、生命周期和失败写进设计
Fetch 只有在网络层失败或请求被取消时才会 reject，HTTP 404 或 500 仍需要应用检查状态码。URL 和 History 适合表达可分享、可恢复的导航状态；Web Storage 适合少量同步偏好，IndexedDB 适合较大或需要事务的数据；Worker 可以转移 CPU 工作，却仍要定义消息协议、错误处理和终止条件。
缓存、存储和 Service Worker 都会引入“页面看到哪个版本”的问题。每份数据都应说明键、身份范围、寿命、失效者和清理方式。CORS 决定浏览器能否读取跨源响应，CSP 约束资源和脚本来源，权限 API 管理部分宿主能力；它们都不能替服务端判断当前用户是否有权执行操作。
用技术目录串起五个部分
贯穿示例从语义 HTML 开始：页面即使没有脚本，也能说明用途和主要内容。CSS 负责不同视口、缩放和动效偏好下的可读性。JavaScript 读取 URL、加载目录并维护查询、选择和详情状态；TypeScript 在共享 JSON 进入应用时验证结构；Fetch、History、Storage 和 Worker 分别承担加载、恢复、偏好和计算任务。
一次正常验收应完成这些用户动作：从可分享 URL 进入目录，使用键盘筛选和打开详情，快速改变输入时不会出现旧结果，刷新后可恢复公开状态，网络或存储失败时仍能看到清楚说明。检查时同时观察 DOM 与可访问性信息、计算样式、请求顺序、存储内容、性能轨迹和控制台错误。
运行仓库中的自动检查：
pnpm install --frozen-lockfile
pnpm --filter @roadmap/web-foundations test启动可交互示例：
pnpm preview数据条目数量会随项目更新，因此验收不依赖某个写死的数字。页面显示的总数应与当前数据源一致；搜索、URL 恢复、选择上限、Worker 降级和异常输入都应通过对应测试。自动测试负责确定性行为，键盘、读屏、缩放、窄屏和多浏览器表现仍需人工检查。
一次完整的故障复盘
假设用户在弱网下填写检查记录，页面提示已经保存，随后却发现服务端没有更新；另一个标签页又显示记录已被同事修改。排查时先固定 URL、时间、身份、输入和页面版本，再判断浏览器是否真正发出请求、服务端是否确认、后续读取是否命中了旧数据。
如果请求没有发出，回到表单语义、资源加载和事件绑定；如果客户端没有收到响应，不能据此推断服务端没有处理，需要用操作 ID 和幂等查询确认；如果服务端已经确认而页面仍旧，应检查缓存键、版本和跨标签同步。草稿是否安全、用户能否重试或导出、冲突怎样比较，也要在根因尚未完全查明时给出明确答案。
复盘记录应区分事实、推断和待验证假设。网络中的请求 ID、存储错误和页面构建版本属于事实；“旧响应覆盖了新状态”是需要实验验证的推断。修复后补上最小回归测试，并考虑怎样让下次定位更快，例如保存操作 ID、显示可恢复错误或在发布前模拟旧资源。
进入前端框架阶段
继续学习框架前，应能独立解释一条操作从 HTML、样式、事件和异步任务，到数据验证、网络、缓存、存储与最终绘制的全过程。还要能回答：状态由谁拥有，旧工作怎样取消，外部输入何时可信，缓存按什么范围隔离，失败时用户怎样恢复。
接下来可阅读 前端框架，比较 React、Vue、Angular、Svelte 及其服务端方案如何组织同一组浏览器事实。遇到框架特有 API 时，先问它管理的是 DOM 更新、状态依赖、请求生命周期还是服务端边界，再判断抽象带来的收益和成本。
相关内容：