从服务器、API、HTTP、日志、缓存、GIT到接口文档。
先不急着写代码，先看懂一次请求从哪里来、到哪里去，后端在中间做了什么。
后端的核心任务很明确：接收客户端请求，处理业务逻辑，访问数据库或第三方服务，最后把结果返回给前端。
API 是“我发什么，你回什么”的约定。它通常不直接面向人看，而是面向前端、App、脚本或别的服务使用。
浏览器和服务器之间主要靠 HTTP 通信。你会频繁看到 GET、POST、状态码、请求头、响应体这些概念。
JSON 是后端最常见的返回格式，数据库则负责长期保存数据，像用户、订单、文章这类信息都离不开它。
这一页只讲分类：GET 负责拿数据，POST 负责提交数据，PUT / DELETE 留到进阶阶段再展开。
后端接口主要基于 HTTP 协议实现，按请求方式可以分成几类。培训里最先要掌握的是 GET 和 POST。
它适合查询、获取和展示数据，通常不改变服务器状态。
GET 用于从服务器读取资源，不应该带来数据修改。
常见形式是查询字符串，复制、调试都很方便。
要数据，放 URL，能缓存，会重复，别传密。
它适合登录、注册、创建和表单提交，通常会改变服务器状态。
POST 用于把数据提交给服务器，常用于创建、保存和执行操作。
常见是 JSON、表单或文件上传，适合承载较多内容。
要提交、要改状态、要传多数据，优先 POST。
读取题目只是获取数据，不改变服务器状态，所以用 GET。提交答案会改变状态，所以用 POST。
搜索图书是读取数据，借阅图书会创建记录、改变库存状态，所以两者的请求方式不同。
GET 的参数会出现在地址栏和日志里，不适合传递敏感信息；POST 把内容放在请求体中，更符合登录这类提交场景。
看接口文档时，先找请求地址和方法，再看参数，最后看返回值和状态码，就不容易迷路。
| 要素 | 说明 | 例子 |
|---|---|---|
| 接口名称 | 这个接口是干什么的 | 用户登录接口 |
| URL | 请求地址 | /api/v1/login |
| 请求方法 | GET / POST / PUT / DELETE | POST |
| 请求参数 | 路径、查询、请求体参数 | {"username":"张三"} |
| 返回结果 | 成功时返回什么 | {"code":0,"data":{...}} |
| 状态码 | 200、404、500 等 | 200 / 404 / 500 |
拿到文档后，先手动拼一次请求，再交给 Postman、curl 或 Codex 生成调用代码，学习效率会更高。
字段清楚、层级简单，最适合做成讲义里的标准格式，重点内容一目了然。
可以直接点 Try it out 试运行，特别适合联调阶段快速验证接口是否可用。
写提示词、贴给 Codex、发群里临时说明，都很方便，虽然轻量但传播效率高。
先看地址和方法，再看参数表，最后看响应结果。
消息推送接口，地址 + 方法 + 参数 + 响应 的完整链路。
| 参数名称 | 类型 | 必填 | 示例 | 备注 |
|---|---|---|---|---|
| robot | string | 必填 | buzhivip | 微信机器ID |
| wxid | string | 必填 | wx_1234d | 用户微信ID |
| type | int | 必填 | 1 | 消息类型：1文字 2图片 |
| content | string | 必填 | 你好 | 文字内容、图片 url 地址 |
课堂上可以把这个返回值当成“接口调用成功后拿到的结果”，再继续讲 code、message 和 data 分别代表什么。
http://apidoc.gwy1.com/project/57/interface/api
通过浏览器来演示GET、POST 请求
配置文件的核心，就是让同一套代码适配不同环境，同时避免把密码、密钥和可变行为写死在代码中。
代码负责逻辑，配置负责环境，敏感信息永远不要硬编码。
PORT=8787
SQLITE_PATH=../dialogue-runtime-core-data/runtime.sqlite
STRATEGY_PACK_PATH=./strategy_packs/public_exam_phone_cta_strategy_pack_v0.2.yaml
LLM_PROVIDER=openai_compatible
LLM_BASE_URL=https://api.deepseek.com
LLM_API_KEY=sk-c6fxxxxxx
LLM_MODEL=deepseek-v4-flash
LLM_STREAM=false
先把“端口”理解成一台主机上的门牌号，再看程序怎样绑定端口，最后理解一个 IP 为什么能同时跑多个服务。
IP 是大楼地址，端口是房间号，程序就是房间里真正接收消息的人。
端口号解决的是“同一台机器上多个程序如何不打架”的问题，也顺带解释 localhost、80、8080 这些常见现象。
一个 IP 像一栋楼，端口像房间号，程序就是住在房间里的人。
日志是后端程序运行过程中的记录。出问题先看日志，通常就能快速缩小范围。
后端日志记录程序运行状态中的关键信息和错误信息，主要用来调试、排查问题和监控运行情况。日志通常保存在服务器本地，方便后续查看分析。
开发看 Debug，监控看 Info，异常先看 Warn，出错重点查 Error。
不同级别的日志，关注点不一样。先分清“记录什么”，再决定“要不要重点处理”。
记录最详细的执行过程，比如接口参数、返回结果、分支判断等。开发阶段最常用，上线后通常关闭。
记录程序正常运行的关键信息，比如启动成功、接口调用成功，主要用于观察系统状态。
记录潜在问题，比如参数不规范、数据异常，但程序还能继续运行，提醒尽快排查。
记录真正的错误，比如代码报错、接口失败、数据库连接失败，是定位问题的重点依据。
Debug 看过程，Info 看状态，Warn 看风险，Error 看故障。
调用任何第三方接口时，把接口位置、请求方式、请求头和请求体说清楚，Codex 才能正确生成代码。
把 URL、方法、请求头、请求体说完整，再补上语言和库，接口代码就更容易一次写对。
接口调用时，先按场景写出 URL、方法、请求头和请求体，再让 Codex 生成代码，效率最高。
适合公开 API 或查询类接口，重点是把 URL 说完整，并说明要取哪个字段。
适合需要认证的接口，通常要明确请求头和 JSON 请求体结构。
先把场景、方法、认证和请求体说清楚，再让 Codex 按模板生成代码。
缓存的目标很简单：减少数据库访问次数，提升数据查询速度，让接口响应更快。
需要设置失效时间，避免缓存数据和数据库数据长期不一致。
Redis 支持多种数据类型，性能高、容量大，是入门阶段必须了解的缓存工具。
例如首页列表、热门数据、用户基础信息，都很适合放缓存。
先查缓存，命中就直接返回，没命中再查数据库并写回缓存。
Git 不是只给程序员用的，它更像版本时光机和团队协作白板，适合管理文档、表格、设计稿和代码。
分支就像建议模式或草稿副本，先单独改，确认后再合并到主稿。
先同步，再修改，再提交，这是团队里最常见、最稳妥的工作节奏。
第一次接手项目时使用 `git clone`，把仓库复制到自己的电脑。
修改文档、表格或设计稿，完成后再统一检查变更。
用 `git add .` 把需要提交的文件放进暂存区。
用 `git commit -m "说明"` 记录这次改了什么。
用 `git push` 把本地版本同步到远程仓库。
每天开始工作前先 `git pull`，避免和别人冲突。
第 1 步只需要做一次，之后通常重复“修改 - 暂存 - 提交 - 推送”，开始前记得先拉取。
命令不需要一次全记住，先知道每条命令在做什么，实际操作时再对照使用。
| 命令 | 作用 | 什么时候用 |
|---|---|---|
| git clone [地址] | 把远程仓库复制到自己的电脑 | 第一次接手项目，先把仓库拉到本地 |
| git status | 查看当前哪些文件被修改了 | 每次提交前先确认有哪些改动 |
| git add . | 把需要提交的文件放进暂存区 | 准备提交前，先选择要保存的内容 |
| git commit -m "说明" | 创建一个版本快照，并写清楚改动 | 完成一组修改后，保存成一个版本 |
| git push | 把本地改动上传到远程仓库 | 本地确认没问题后，同步给团队成员 |
| git pull | 从远程仓库拉取最新版本 | 每天开始工作前，先同步队友的更新 |
先看状态，再选择改动，提交后推送，开始前先拉取。
不会命令行也没关系，图形化工具同样能完成克隆、提交、推送和拉取。