做产品 PMaker
浏览器
我的订单
前端
请求


响应
服务器
GET /api/orders
校验登录态
查这个人的订单
200 [ …12 条 ]
后端



数据
数据库
iduseramount
2048u_31124.00
2047u_3138.80
2046u_88271.50
存储

你在屏幕上看到的每一条数据,都走过这条路。理解这张图,就够跟 AI 和工程师对话了。

理解技术

你不需要会写代码,但需要知道一件事发生在哪一层。分不清层,提的需求就会落空,看到的报错也读不懂。

读完你能回答
  • 「这个改前端就行」和「要动后端」的区别在哪
  • 为什么登录状态会莫名其妙掉,token 是个什么东西
  • AI 写的代码里,哪几个地方是安全隐患的高发区

前端和后端

一句话分界:能在用户浏览器里改的是前端,必须在你服务器上算的是后端。凡是牵扯钱、权限、别人的数据,一定在后端。

这件事在哪一层为什么
按钮改个颜色前端纯展示,跟数据无关
列表加个筛选前端后端数据量小前端筛,量大要后端出接口
判断能不能删后端前端的判断能被绕过,权限必须在后端拦
算价格和优惠后端前端算的价格用户能改,这是常见的漏洞
页面加载慢看情况可能是图片太大(前端),也可能是查询太慢(后端)
最容易出事的是第四行。让 AI 做一个下单页面,它经常把价格计算写在前端,用户改一下就能一块钱下单。

登录是怎么回事

登录不是「验证一次就完了」,而是「验证一次,之后每次请求都带着一张凭证」。

用户这边 服务器这边 账号 + 密码 核对,签发凭证 存下 token 之后每次请求都带上它 验凭证,认人 只在登录这一次传密码
登录状态掉了,多半是这张凭证过期了或者被清掉了。凭证有有效期,这是安全设计,不是 bug。

数据库长什么样

就是一张张表。每张表存一类东西,表之间靠 id 关联。你画数据模型的时候,画的就是这个。

users 表
idnamecreated_at
u_31李明2026-03-04
u_88王芳2026-05-19
orders 表
iduser_idamountstatus
2048u_31124.00已付
2047u_3138.80待付
orders 表里的 user_id 指向 users 表的 id,这就是「关联」。一个用户对应多条订单,叫一对多。数据模型定错,界面上就会出现「一个订单显示了两个收货人」这类改不动的问题。

部署与环境

同一份代码会跑在三个地方,出问题时先问清楚是哪一个。

环境谁在用数据是真的吗
本地只有你自己假数据,随便删
预发你和少数几个人验收接近真实,但删了不心疼
线上所有真实用户真的,删了就没了
让 AI 帮你跑数据库脚本之前,先确认它连的是哪个环境。这是 vibecoding 里最容易造成不可逆损失的一步。

六个安全常识

AI 写的代码在这六个地方翻车最多,每次生成完扫一眼。