理解浏览器、服务器和服务之间如何交换数据。
多租户 SaaS、项目与协作、数据看板、订单与支付、实时协作等场景
网络通信让不同设备和程序按照协议发送请求、返回响应或持续传递事件。
API、登录、文件上传、实时协作和 AI 流式输出都建立在网络通信之上。
位于客户端、后端和外部系统之间，是所有跨进程协作的通道。
URL、DNS、IP、端口、HTTP、API、WebSocket、Webhook 和 OpenAPI。
前端请求项目列表、支付平台回调、服务间调用都属于网络通信。
域名需要先找到服务器地址，浏览器再与目标端口建立连接。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
用户访问 acme.example.com，希望进入自己公司的工作区。
域名需要解析到服务器，服务器上可能同时运行多个应用和租户入口，端口也不能直接暴露给用户。
DNS 把域名解析为 IP，请求到达 443 端口，再由反向代理把子域名路由到对应应用。
域名错误、解析中、证书异常和租户不存在都需要独立的反馈页面。
URL 包含协议、域名、路径和查询参数。DNS 把容易记忆的域名解析成 IP 地址，端口用于区分同一台机器上的不同网络程序。
浏览器通过 HTTPS 与服务器建立加密连接，请求路径对应页面或 API。CDN、负载均衡和反向代理可能位于真正应用之前。
URL 结构既是技术入口，也影响产品信息架构、可分享性和可追踪性。
HTTP 规定客户端和服务器如何描述一次请求与结果。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
用户修改项目名称并点击保存。
服务端需要知道用户身份、数据格式和具体修改内容；网络传输也要防止被窃听和篡改。
请求 Header 携带认证和内容类型，Body 携带项目字段，HTTPS 加密传输，服务端返回状态码和 JSON。
错误提示要区分字段问题、登录失效、网络中断和服务器故障。
Request 通常包含 Method、Path、Header 和 Body。Header 放认证、内容类型等元信息，Body 放表单或 JSON 数据。
Response 包含状态码、Header 和 Body。前端根据状态码与数据决定展示成功、错误、重试或登录页面。HTTPS 在 HTTP 外增加传输加密和身份验证。
POST /api/projects HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json
{"name": "新项目"}
→ 201 Created接口状态需要映射成明确 UI：加载、成功、参数错误、未登录、无权限、服务器异常。
Method 表达意图，状态码表达处理结果。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
用户查看项目列表、新建项目、修改状态和删除草稿。
接口动作含糊会让前后端难以约定，错误码不清会让页面只能统一显示“操作失败”。
GET 查询、POST 创建、PATCH 更新、DELETE 删除；201 表示创建成功，401 表示未登录，403 表示无权限，409 表示冲突。
为每类状态码设计明确反馈和恢复动作，尤其是 409 冲突与 422 字段校验。
GET 常用于查询，POST 用于创建，PUT 或 PATCH 用于更新，DELETE 用于删除。接口命名通常围绕资源组织。
2xx 表示成功，4xx 表示请求、身份或权限问题，5xx 表示服务器内部问题。相同页面在不同状态码下需要不同反馈。
删除按钮的二次确认、保存冲突提示和无权限状态，都能追溯到接口语义。
它们都解决程序调用能力的问题，表达方式和适用场景不同。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
移动端看板只需要项目名称和三个指标，桌面端还需要趋势、成员和风险明细。
固定 REST 返回可能在移动端传输过多数据，多个接口又会增加往返次数。
GraphQL 允许客户端声明需要的字段；普通 CRUD 仍可用 REST；内部高频服务通信可使用 gRPC。
设计数据密集型页面时标注首屏必需数据、延迟加载数据和不同端的数据差异。
用户提交订单时，订单服务需要快速确认库存并锁定商品。
内部服务调用频繁，接口契约和性能要求更高。
订单服务通过强类型 gRPC 契约调用库存服务，外部客户端仍通过 REST 访问网关。
产品层关注整体等待时间和失败恢复，不需要暴露内部通信形式。
REST 以资源和 HTTP 语义组织接口，适合通用 Web API。GraphQL 让客户端声明所需字段，适合数据关系复杂的界面。
RPC 更像调用远程函数，gRPC 基于严格的接口定义和高效传输，常用于内部服务之间。架构选择还要考虑团队、工具链和调试成本。
设计师无需决定协议，但要知道接口形态会影响加载、分页、错误和实时反馈。
实时数据和系统回调需要不同于普通请求的通信方式。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
两名成员同时编辑同一份需求文档。
普通请求只能由客户端主动发起，频繁轮询会产生延迟和大量无效请求。
WebSocket 建立持续双向连接，服务端把编辑操作和在线状态实时推送给其他客户端。
需要设计在线成员、正在输入、断线重连、冲突、离线草稿和同步失败。
用户生成报告，希望立即看到内容进展并随时停止。
等待完整结果会造成长时间空白，也无法判断任务是否还在运行。
SSE 让服务端持续单向推送生成片段，前端逐步追加到页面。
需要设计生成中、停止、断线、部分结果保留和继续生成。
用户跳转到支付平台完成付款。
商城无法预测付款完成时间，用户也可能直接关闭支付页。
支付平台通过 Webhook 主动通知商城，商城验证签名后更新订单。
支付结果页要支持处理中、自动查询、回调延迟和人工对账。
WebSocket 建立双向长连接，适合聊天、协同编辑和实时控制。SSE 让服务器持续向浏览器单向推送，AI 流式输出常使用它。
Webhook 是系统间回调。支付平台、代码托管平台或表单服务发生事件后，会主动向你的后端发送 HTTP 请求。
实时体验要设计连接中断、重连、延迟、重复消息和处理中状态。
机器可读的接口契约让人、工具和 AI 对能力形成同一理解。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
Java 后台、Python 脚本和 AI Agent 都需要调用 Excel 导出能力。
参数名称、字段类型、错误码和返回格式不统一，会导致重复沟通和错误调用。
OpenAPI 用机器可读的 Schema 描述接口，Swagger 提供查看和调试页面，也能生成客户端代码或工具定义。
接口文档中要明确数据量限制、任务状态、失败原因和下载有效期。
OpenAPI 描述路径、方法、参数、数据结构、认证方式和响应。Swagger UI 等工具可以把规范渲染成可浏览、可调试的文档。
清晰契约支持前后端并行开发、生成客户端代码、自动测试和 AI Tool Calling。接口名称清楚仍然不够，输入、输出、限制和错误都需要明确。
当团队讨论“组件服务化”时，文档和接口契约就是可用性的核心部分。
说明文字帮助阅读；机器可读的 Schema、参数和响应定义才能支持自动生成与校验。
打开浏览器开发者工具的 Network，观察一次列表请求的 URL、Method、Status、Request Header 和 Response JSON。