跳转到内容
IndieMaker 标志 IndieMaker 标志 IndieMaker
搜索全站 提交项目
全站

互联网产品到底由什么组成

零基础入门 · 零基础 · 90-120 分钟

跟着一次“点击提交”走一遍：域名、部署、前端、API、后端、数据库和支付分别在做什么。

未核验

互联网产品到底由什么组成 配图
学习结果
画出一张产品结构图，能说清用户点一次按钮后每一层发生了什么，出问题时知道先查哪一层。
时长
90-120 分钟
难度
零基础
核验
未核验

正文

刚开始做产品的人，最常见的困惑不是“某个技术怎么用”，而是“我说不清问题出在哪儿”。页面打不开、按钮点了没反应、提交了数据却不见了，看起来都是“网站坏了”，但它们发生在完全不同的地方，要找的人、要查的东西也不一样。

这篇不按名词表一个个解释，而是跟着一次真实的操作走一遍：一个用户打开某个网站的“提交项目”页面，填完表单，点击提交。整个过程走完，七八个概念就都出现了。

一次点击背后的链路

一次点击背后的链路

1. 输入网址：域名和 DNS。 用户在浏览器里输入 example.com。域名只是一个好记的名字，浏览器真正需要的是服务器的地址。DNS 负责把名字翻译成地址，可以把它理解成互联网的通讯录。域名解析配置错了，后面的代码写得再好，用户也打不开页面。

2. 拿到页面：部署平台。 浏览器按地址找到托管网站的地方，比如 Cloudflare Pages、Vercel 或一台云服务器。部署，就是把你写好的代码和图片放到这些地方，让任何人都能访问。部署平台返回 HTML、CSS、JavaScript 等文件。

3. 显示和交互：前端。 浏览器把这些文件变成用户看到的页面：标题、输入框、按钮。前端负责的不只是好不好看，还包括用户能不能看懂、能不能找到入口、填错时有没有清楚的提示。比如用户没填项目名就点提交，前端可以马上提示“请填写项目名称”，不用等服务器回复。

4. 发出请求：API。 用户点击提交后，前端把表单内容打包，按约定好的格式发给服务器，这个约定就是 API。可以把 API 理解成一个办事窗口：窗口规定了要交哪些材料、什么格式，办完给你什么回执。

5. 执行规则：后端。 服务器收到请求，开始执行那些不能放在用户浏览器里的规则：再检查一遍必填项和链接格式（前端的检查可以被绕过，后端必须再查一次）、判断这个项目是否已经提交过、记录提交时间、把状态设为“待审核”。登录权限、订单状态、敏感配置也都在这一层处理。

6. 长期保存：数据库。 后端把整理好的数据写进数据库。数据库按表保存结构化的信息：项目表、用户表、订单表。和随手记的表格不同，它要考虑字段类型、表之间的关系、谁能读写，以及怎么备份。

7. 返回结果：回到前端。 后端告诉前端“保存成功”，前端显示“已收到，等待审核”。注意顺序：只有后端确认保存了，前端才能显示成功。如果前端一点按钮就显示成功，用户以为提交了，数据其实可能丢在半路。

8. 后台和公开展示。 管理员在后台看到这条待审核的提交，通过后，它出现在公开的项目列表里。公开页面读的是数据库里“已通过”的记录，不包括提交者的联系方式。

如果这个产品还要收费，链路里会多一个支付平台：用户在支付平台的页面付款，支付平台再通过回调（webhook）通知你的后端“这笔钱到了”，后端据此开通权限。付款这一步发生在别人的系统里，所以“支付成功之后发生什么”需要你自己设计。

不是每个产品都需要每一层

很多内容网站、作品集、资料库只有前端和部署：页面在构建时就已经生成好，不需要后端和数据库。这种网站叫静态网站，成本低、出错少，非常适合作为第一个作品。

一旦出现下面这些需求，就需要后端或者现成的后端服务：用户要登录；用户要提交内容并长期保存；付款后要开通权限；有需要保密的配置，比如第三方服务的密钥。判断标准很简单：有没有不能交给用户浏览器决定的规则，或者需要长期保存的用户数据。

静态网站与需要后端的网站

出问题时先查哪一层

理解了链路，排查就有了方向。按症状对应到层次，先查最可能的地方：

现象 先查
网址完全打不开、提示找不到服务器 域名解析、部署状态
页面能打开，但排版乱、按钮没反应 前端代码，浏览器控制台里的报错
点了提交显示失败，或一直在加载 API 请求和后端日志
显示成功，但数据没出现在后台 后端是否真的写入，数据库记录
付了款却没开通 支付回调是否收到、权限状态是否更新

这张表也是你和 AI 或开发者沟通的基础。与其说“网站坏了，帮我修”，不如说“页面能打开，点提交后控制台报 500 错误，后台没有新记录”，对方能直接定位到后端，效率完全不同。

读完能做到什么

不需要记住所有术语。只要能用自己的话讲清一次操作经过了哪些层，能判断一个需求要不要后端，遇到问题时知道先看哪里，就够了。这是后面学编程、写需求、和 AI 协作的共同基础。

学习步骤

  1. 挑一个你常用网站上的表单，写下你从打开页面到看到结果的每一个动作。
  2. 给每个动作标上它发生在哪一层：浏览器、前端、API、后端、数据库或第三方服务。
  3. 判断这个功能里有没有必须由后端执行的规则，写下理由。
  4. 列出这个功能需要长期保存的字段，区分公开字段和只给后台看的字段。
  5. 画一张从域名到数据库的结构图，在箭头上写清数据怎么流动。
  6. 对照“先查哪一层”的表，为这个功能写出三种可能的故障和对应的排查位置。

场景拆解

拆一个“提交项目”功能

假设你要做一个页面，让独立开发者提交自己的项目：填写项目名、官网、简介和联系邮箱，管理员审核后公开展示。

  1. 用户路径：打开提交页 → 阅读说明 → 填写四项信息 → 点击提交 → 看到“已收到，等待审核”。
  2. 前端：标题和说明、四个带标签的输入框、提交按钮、加载状态、成功和失败提示。
  3. 后端规则：必填检查、网址格式检查、同一官网是否重复提交、记录提交时间、状态设为“待审核”。
  4. 数据库：一张提交表，字段有项目名、官网、简介、联系邮箱、状态、提交时间。联系邮箱只在后台可见。
  5. 后台与公开页：管理员通过后，公开列表只读取“已通过”的记录，并且不显示联系邮箱。

拆完之后应该能回答：哪一步失败会导致“显示成功但数据丢了”？答案是前端在后端确认之前就显示了成功。这就是为什么成功提示必须等后端返回。

补充材料

思维导图、练习、清单和参考资料可按需展开。

01

思维导图和离线文件

适合读完后下载到自己的知识库里继续整理。

一次点击的链路

  • 域名与 DNS：找到服务器
  • 部署平台：返回页面文件
  • 前端：显示页面、初步检查
  • API 与后端：执行规则
  • 数据库：长期保存
  • 前端：等后端确认后显示结果

什么时候需要后端

  • 用户要登录
  • 用户提交的内容要长期保存
  • 付款后要开通权限
  • 有需要保密的配置

出问题先查哪一层

  • 打不开：域名与部署
  • 排版或交互异常：前端
  • 提交失败：API 与后端
  • 显示成功却没数据：数据库写入
  • 付款没开通：支付回调

互联网产品到底由什么组成 思维导图

下载 Markdown 下载 FreeMind 下载 OPML
02

实践练习

根据文章内容记录自己的判断与依据。

把一个真实功能拆成结构图

选一个你熟悉的表单（报名、反馈、投稿、下单都可以），产出一张能讲给别人听的产品结构图。

准备材料

  • 纸笔、白板，或 Excalidraw 这类画图工具。
  • 一个你能实际打开的网站表单。

练习步骤

01 / 写出用户动作

时间： 15 分钟

操作：

  1. 按顺序写下用户的每个动作，每个动作一句话。
  2. 先不要用任何技术名词。

产出： 一条 6 到 8 步的用户路径。

检查： 一个不懂技术的人能看懂这条路径。

02 / 标出每一步所在的层

时间： 20 分钟

操作：

  1. 给每个动作标上浏览器、前端、API、后端、数据库或第三方服务。
  2. 写出哪些检查只在前端做、哪些必须在后端再做一次。

产出： 一张“动作—层次—检查规则”对照表。

检查： 能说明为什么只靠前端检查不够。

03 / 列出要保存的数据

时间： 20 分钟

操作：

  1. 把用户填写的每一项写成字段，注明类型（文本、网址、时间、状态）。
  2. 补上系统自己要记录的字段，比如提交时间和审核状态，并标出哪些字段不公开。

产出： 一张字段表。

检查： 这张表能同时支持公开列表和后台审核。

04 / 合成结构图

时间： 30 分钟

操作：

  1. 从左到右画出用户、浏览器、部署平台、前端、API、后端、数据库，以及后台和公开页面。
  2. 在箭头上写清每一步传递的是什么。

产出： 一张产品结构图。

检查： 拿着这张图，能向 AI 或开发者说清这个功能要做什么、数据去了哪里。

完成检查

  • 能讲清一次点击从域名到数据库的完整路径。
  • 能判断一个需求是否需要后端。
  • 能针对三种故障说出先查哪一层。
03

清单、模板和关键词

用于项目记录和自查。

功能拆解模板

功能名称：
用户动作（按顺序）：
页面上需要的元素：
前端检查：
后端必须执行的规则：
需要保存的字段（标出不公开的字段）：
成功时显示：
失败时显示：
涉及的第三方服务：

故障描述模板

发生在哪个页面：
我做了什么操作：
期望看到：
实际看到：
浏览器控制台有没有报错（原文）：
后台或数据库里有没有对应记录：

关键概念

  • 域名与 DNS：把好记的名字翻译成服务器地址
  • 部署：把代码和资源放到用户能访问的地方
  • 前端：用户看到和操作的部分
  • API：前端和后端之间约定好的请求格式
  • 后端：执行不能交给浏览器的规则
  • 数据库：长期保存结构化数据
  • 静态网站：页面提前生成好，不需要后端
  • 回调（webhook）：第三方服务主动通知你的后端

容易误判

  • 前端一点按钮就显示成功，没等后端确认
  • 只在前端做检查，以为后端不用再查
  • 把联系方式这类后台字段直接显示在公开页面
  • 第一个作品就上全套后端和数据库
  • 遇到问题只说“网站坏了”，不说明现象和位置
04

工具和参考资料

本篇涉及的工具和参考链接。

可参考工具

  • Excalidraw
  • Notion
  • 浏览器开发者工具
  • Cloudflare Pages
  • Vercel

参考资料