一、入参与出参
在程序接口设计中，明确区分入参（输入参数）和出参（输出参数）是保证接口清晰、易用和可维护的关键。
1. 入参（Input Parameters）
定义：入参是调用接口时由客户端（调用方）传递给服务端（被调方）的数据，用于影响接口的内部逻辑或查询条件。
特点
方向：客户端 → 服务端。
用途：过滤数据、配置行为、身份验证等。
常见形式：
URL 查询参数（GET 请求）：/api/users?name=John&age=20
请求体（POST/PUT 请求）：JSON、XML 或表单数据。
路径参数：/api/users/{id} 中的 {id}。
请求头（Headers）：如 Authorization: Bearer token。
RESTful API 示例:
GET /api/users?role=admin&active=true
Headers:
Authorization: Bearer xxx
入参：
查询参数：role=admin, active=true
请求头：Authorization
2.出参（Output Parameters）
定义: 出参是接口返回给客户端的数据，通常是接口处理后的结果或状态信息。
特点
方向：服务端 → 客户端。
用途：返回请求的数据、操作结果或错误信息。
常见形式：
响应体（JSON/XML/Protobuf 等结构化数据）。
状态码（HTTP 状态码，如 200 OK、404 Not Found）。
响应头（Headers）：如 X-RateLimit-Limit。
RESTful API 示例:
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": "123",
"name": "John",
"email": "john@example.com"
}
出参：
响应体：JSON 格式的用户数据。
状态码：200 OK。
3. 如何明确区分入参和出参？
(1) 通过协议规范区分
(2) 通过代码注释或文档
Swagger/OpenAPI：明确标注 parameters（入参）和 responses（出参）。
paths:
/api/users:
get:
parameters: # 入参
- name: role
in: query
type: string
responses: # 出参
200:
description: OK
schema:
$ref: '#/definitions/User'
代码注释：在函数或方法中明确标注参数方向。
def get_user(user_id: int, include_profile: bool) -> dict: # user_id 和 include_profile 是入参
# ...
return {"id": user_id, "name": "John"} # 返回值是出参
(3) 通过命名约定
入参命名：常用 request、query、params 等前缀或后缀。
例如：GetUserRequest（gRPC）、userQueryParams（REST）。
出参命名：常用 response、result、data 等前缀或后缀。
例如：GetUserResponse（gRPC）、userData（REST）。
二、浏览器里面的preview 和 response 有什么区别？ 里面的内容是一样的吗？
在浏览器的开发者工具（如 Chrome、Firefox 的 DevTools）中，当你在 Network（网络） 面板查看某个请求（比如一个 API 请求或页面资源加载）时，通常会看到如下几个重要标签页或区域：
Preview（预览）
Response（响应）
1. Response（响应）是什么？
Response 是服务器返回的 原始数据内容，也就是 HTTP 响应的 Body 部分，未经任何格式化处理。
它是 纯粹的、原生的响应数据，直接展示了从服务器返回的内容，包括：
(1)JSON 数据（原始 JSON 字符串）
(2)HTML 页面源码
(3)XML 数据
(4)图片、文件等二进制内容的文本编码（可能显示为乱码）
(5)纯文本、脚本、样式表等
用途:
用于 查看服务器返回的原始内容，适合开发者调试 API 返回的数据结构，或者查看 HTML、JSON 等内容是否正确。
如果你是一个开发者，想 直接看到服务器返回了什么，通常先看 Response。
内容示例：
假设你请求了一个 API 接口 https://api.example.com/user/1，服务器返回了如下 JSON 数据：
{"id": 1, "name": "Alice", "email": "alice@example.com"}
那么在 Response 标签页里，你将直接看到这段 原始 JSON 字符串：
{"id": 1, "name": "Alice", "email": "alice@example.com"}
2. Preview（预览）是什么？
Preview 是浏览器对 Response 返回内容 的 自动解析和格式化展示，目的是让数据 更易于人类阅读。
它会根据 响应内容的类型（Content-Type），自动对返回的数据进行 格式化渲染，比如：
(1)如果返回的是 JSON，Preview 会把 JSON 数据以 树状/结构化形式展示，方便查看键值对。
(2)如果返回的是 HTML，Preview 可能会尝试渲染成一个简易的页面预览（但通常不如直接看 HTML 源码或实际渲染的页面）。
(3)如果是图片、PDF 等二进制文件，Preview 可能会直接显示图片或提示下载，而不是展示原始内容。
用途
用于 快速查看和理解服务器返回的数据内容，特别是对于结构化数据（如 JSON、XML）。
更 直观、友好，适合快速检查 API 返回的数据是否正确，不需要手动解析 JSON 字符串。
内容示例:
还是上面那个 API 返回的 JSON 数据：
{"id": 1, "name": "Alice", "email": "alice@example.com"}
在 Preview 标签页里，你可能会看到如下 结构化、可折叠的树形展示：
Object
├── id: 1
├── name: "Alice"
└── email: "alice@example.com"
你可以通过展开节点快速查看每个字段的值，而无需自己分析原始 JSON 字符串。
如果是 HTML，Preview 可能会尝试渲染一个简单的页面视图（但通常不完整）；如果是图片，则可能直接显示图片预览。
3. 两者的主要区别总结
4. 内容一样吗？
从数据本质上来说，Preview 的内容来源于 Response，它们展示的是同一个 HTTP 响应的 Body 数据。
但展示形式完全不同：
Response 是原始形式（如纯 JSON 字符串、HTML 源码）。
Preview 是经过浏览器解析和格式化后的形式（如树状 JSON、简易页面渲染）。
✅ 所以：内容本质一样，但展示方式不同！
5. 实际使用建议
什么时候看 Response？
你想 查看服务器返回的原始数据（比如调试 API 返回的 JSON 字符串、HTML 源码）。
你想 确认返回的内容是否完全符合预期（比如检查是否有额外的空格、换行、隐藏字符）。
你正在处理 二进制数据 或需要查看原始格式的内容。
什么时候看 Preview？
你想 快速查看 JSON/XML 数据的结构，而不需要手动解析字符串。
你想 直观地检查 API 返回的数据值（比如字段是否正确、数据类型是否对）。
你对数据的 可读性 要求更高，希望一目了然。
6. 示例对比（JSON 数据）
假设 API 返回如下 JSON 数据：
{"status": "success", "data": {"id": 1, "name": "Bob"}}
在 Response 中你看到的是：
{"status": "success", "data": {"id": 1, "name": "Bob"}}
这是 原始 JSON 字符串，没有格式化.
在 Preview 中你看到的是：
Object
├── status: "success"
└── data: Object
├── id: 1
└── name: "Bob"
这是 结构化、可折叠的树状视图，更直观清晰。
