第二天的工作，重点已经不在"页面长什么样"，而是开始思考：这个网站靠什么活起来。
第一天我把首页结构和视觉大致定下来之后，很快就意识到一个问题------如果所有内容都只是写死在前端，那这个网站本质上还是一张"展示图"，而不是一个正在运转的系统。哪怕是个人站，也应该有最基本的数据流动。
于是第二天的目标变得很明确：引入后端，让页面开始从接口拿数据。
从"项目卡片"开始，而不是从登录开始
我没有一上来就做用户系统、鉴权、数据库那一套。原因很简单：那会让我在"还没决定站点内容形态"的情况下，先陷入技术细节。
相比之下，"项目列表"是一个非常自然的切入点：
-
首页已经有"项目"这个板块
-
项目本身就是这个站点的核心内容
-
即使没有数据库，也可以先用静态数据模拟
于是我决定：先给项目列表一个真实的 API。
用 FastAPI 搭一个"足够真实"的最小后端
后端我用的是 FastAPI。并不是为了炫什么技术，而是它非常适合这种"从 0 到 1"的阶段：结构清晰、反馈快、接口即文档。
这一天我在后端里做了三件事：
-
一个健康检查接口，用来确认服务是否在线
-
一个简单的访问计数接口，用来验证前后端通信
-
一个真正用于业务的
/api/projects接口
项目列表暂时还只是内存中的静态数据，但字段已经按"将来会进数据库"的标准来设计，包括 id、title、summary、tags、status 等。接口也支持按标签和状态筛选，这样前端逻辑就可以提前写好，后面换数据源时不用动页面结构。
后端的整体结构非常克制，没有引入多余的东西，只保证一件事：前端可以稳定地拿到它需要的数据。
main
前端第一次"真正依赖后端"
当我把项目区块从"写死的卡片"改成"从接口拉数据"时，页面的性质发生了变化。
项目列表现在具备了几个特征：
-
页面刷新会重新请求数据
-
标签筛选基于接口返回的 tags 自动生成
-
出错时会有明确的错误提示
-
没有数据时有空状态兜底
这些都不是复杂功能，但它们让这个页面不再只是一个 UI，而是一个可以承受变化的模块。
有一个小插曲是，我在前端第一次请求接口时，报了 API_BASE is not defined。这并不是什么大问题，但它提醒我：项目已经走到需要"配置层"的阶段了，接口地址、环境区分这些概念已经开始出现。这其实是一个好信号。
开始正视"数据库这件事"
当接口跑通、页面也能正常展示项目后，一个问题变得无法回避：这些数据总不能永远放在内存里。
于是第二天的后半段，我开始着手数据库相关的事情，包括：
-
用 DBeaver 连接 MySQL
-
区分本地数据库和服务器数据库
-
明确 MySQL 是通过 Docker 跑的服务，而不是一个"点开就能用的应用"
-
用命令行确认 MySQL 是否真的在运行
这些步骤看起来很基础，但它们是后端工程的地基。只有在这一步不含糊，后面建表、写 ORM、做迁移才不会一地鸡毛。