前端、后端、数据库和 Next.js 路由究竟怎样配合？
沿着一次操作定位页面、接口、数据和外部服务，避免把文件名或是否可见当作运行边界。
本页目录
直接回答
先区分运行环境：浏览器负责交互，服务端负责受信任的数据访问、权限判断和外部服务调用；数据库保存需要长期保留的结构化信息。同一个 Next.js 项目可以同时包含这些能力。“前端管脸，后端管脑”只是一种粗略比喻，把看不见的逻辑都叫后端并不准确，浏览器也会执行计算与状态管理。Next.js App Router 官方文档说明页面和布局默认是服务端组件，需要交互时再使用客户端组件，因此不能只凭 components 目录或 page.tsx 文件名判断运行位置。
适用场景
- AI 修改了很多文件，自己不知道它们负责什么
- 页面显示正常但调用失败，不知从哪里查
- 从在线工具导出项目，准备在本地运行
一步一步做
选一次具体操作作为入口
例如点击发送聊天消息。在页面里找到事件处理代码，继续追踪它调用的函数或接口地址。记下输入是什么、谁发送请求、谁返回结果。不要试图一开始就读完所有文件，先看懂一条实际调用路径。
认识路由和共用界面
在 App Router 中，app/login/page.tsx 对应登录页面，layout.tsx 组织共用布局，app/api/chat/route.ts 可以处理聊天接口。components 存放可复用界面，但运行位置仍取决于组件边界及依赖，不能按目录名称一概判断。
标出信任与数据边界
记录数据库连接、模型密钥与权限检查出现的位置。浏览器提交的用户 ID、价格或角色不能自动当成可信事实。整理建议：把必须可信的判断放在服务端，并在返回页面前只选择用户有权看到的数据。
区分临时状态与持久数据
按钮是否展开、当前输入通常是界面状态；跨刷新保留的历史记录需要明确存储方案。管理游戏状态的 GameContext 管理游戏状态，不能因为有分数计算就叫后端。持久化也不等于一定上远程数据库，要按共享、查询与可靠性需要决定。
本地迁移时列出外部依赖
先认识 IDE 的文件导航、代码编辑、AI 对话和终端四个区域，再检查项目说明、包管理器、Node 要求、启动命令及环境变量名称。用自己的授权配置连接服务，不把密钥贴进聊天。下载后的项目可能仍连接云端数据库和外部 SDK；把代码下载到电脑，只说明开发位置变了，不代表服务已经全部独立。
案例拆解
假设练习：追踪一次游戏请求
用户点选回复后，浏览器向聊天接口提交选择和必要上下文；服务端调用模型并返回回复与规则所需数据；页面更新气泡、轮次和进度条；语音接口再生成音频。GameContext.tsx 的状态更新应按实际运行环境分类，不能因为负责分数计算就自动视为服务端逻辑。如果成绩影响奖励或排行榜，最终成绩还需要可信的服务端校验，不能仅靠浏览器提交的数字。
行动检查
可复制模板
请 AI 解释真实项目
工作模板
先不要改代码。请沿着［用户操作］读取实际调用链，列出：
1. 页面和事件处理文件；2. 请求地址与输入；3. 服务端处理；4. 数据库或外部 API；5. 返回结果如何显示。
标出浏览器／服务端边界、密钥位置、用户权限检查和持久数据。只根据现有实现解释，不把目录名当成证据，不打印凭据。最后指出我还需要确认的事项。
易错点
- 把看不见的逻辑都叫后端：应按运行环境和信任边界判断。
- 以为网页、App 可无条件共享同一后端：接口、认证和平台能力仍可能需要调整。
- 迁移时直接复制平台内部凭据：应采用平台支持且属于自己的授权接入方式。
相关指南
- API Key 和环境变量怎么放，泄露以后先做什么？
- 产品什么时候需要数据库，表和字段应该怎么设计？
- 页面能登录就够了吗，怎样保证用户只能看到自己的数据？
- 怎样把在线工具做出的原型，迁到本地和自己的服务？
官方参考
- Next.js：Server and Client Components — 说明页面与布局默认使用服务端组件，以及交互与 Context 的客户端边界。 资料核查记录日期：2026-10-18。