网站有哪些类型，不能只按“官网、商城、论坛”罗列名称。从开发角度看，网站类型通常由业务目标、用户操作、数据变化方式和系统接口共同决定。常见形态包括静态展示型网站、内容管理型网站、电商或交易型网站、社区互动型网站、SaaS 应用型网站，以及由接口驱动的前后端分离网站。确定类型时，应先明确网站要完成的核心动作，再反推页面、数据模型和接口契约。

例如，企业介绍页主要解决信息展示问题，接口需求较少；商品网站需要处理商品、库存、订单和支付状态；协作平台则需要用户、组织、权限和业务流程。它们都可以被称为网站，但实现复杂度和接口边界并不相同。

先按用户要完成的动作判断网站类型

网站类型	核心用户动作	主要开发对象
静态展示型网站	浏览、了解、联系	页面、素材、基础表单、部署流程
内容管理型网站	发布、编辑、检索内容	文章、栏目、标签、审核和管理端
电商或交易型网站	选择、下单、支付、查询状态	商品、库存、订单、用户和交易状态
社区互动型网站	发帖、评论、关注、互动	用户关系、内容审核、消息和分页查询
SaaS 应用型网站	创建数据、协作、配置流程	组织、角色、权限、工作区和业务规则

静态展示型网站：页面优先，接口保持最小化

企业官网、品牌介绍页、活动落地页和个人作品集，通常属于静态展示型网站。它们的内容更新频率较低，访问者主要进行浏览，不需要复杂的登录、订单或实时数据处理。

这类网站可以直接使用构建后的 HTML、CSS 和图片资源，也可以采用服务端渲染。若页面内容由固定文件或构建流程生成，前端不必为每个模块设计独立业务接口。只有在需要提交咨询、预约或订阅时，才需要增加表单处理能力。

开发时应先确认页面清单、移动端适配、资源加载和表单字段。接口契约只需描述确实存在的动作，例如表单提交所需字段、成功结果和失败提示，不能把不存在的用户系统或内容后台预先写进需求。

内容管理型网站：围绕内容资源设计接口

新闻站、知识库、媒体门户和企业内容中心，需要持续新增、修改、审核和展示内容，属于内容管理型网站。它与静态站的区别不在于页面数量，而在于内容是否由后台持续维护，以及前台是否根据数据动态生成页面。

实现时可以先抽象出内容资源，再确定栏目、标签和作者等关联关系。常见的资源字段包括唯一标识、标题、摘要、正文、封面、状态、创建时间和发布时间。管理端负责创建与审核，前台负责列表、详情、分类筛选和分页展示。

接口契约项目	需要明确的内容
请求条件	栏目、关键词、页码、每页数量和排序方式
返回结构	数据列表、总数量、当前页和分页信息
状态规则	草稿、审核中、已发布、已下线是否允许被前台读取
权限边界	普通用户、编辑和管理员可执行的操作

接口名称和路径应以实际项目约定为准。文档可以使用“内容列表接口”“内容详情接口”等功能名称描述能力，待后端确认资源路径、请求方法和认证方式后再固化为具体契约。

电商与交易型网站：重点是状态和数据一致性

商城、票务、预约和在线服务平台都属于交易型网站。用户看到的页面只是结果，后台还要处理商品或服务信息、价格、库存、订单、支付以及售后状态。

这类网站的开发起点不是先画商品详情页，而是先确定业务状态。例如订单可能经历待确认、待支付、处理中、已完成或已取消等阶段。每个状态允许执行的动作不同，接口也应明确状态变更条件，避免前端直接修改关键状态。

接口契约至少要说明资源标识、操作权限、请求参数、状态变化、失败原因和重复提交处理方式。涉及创建订单、提交预约等动作时，还要约定请求是否支持幂等，库存或名额不足时返回什么结果。支付结果、订单结果和页面提示不能仅凭前端判断，必须以服务端确认的数据为准。

社区互动型网站：把用户关系和内容治理纳入设计

论坛、问答站、评论社区和兴趣平台的核心不是单纯发布文章，而是用户持续产生内容并相互互动。除帖子或问答资源外，系统通常还要处理评论、回复、点赞、收藏、关注和消息等关系数据。

接口设计要同时考虑内容读取和用户操作。列表接口需要明确排序、分页和可见范围；创建或修改接口需要检查登录状态、作者权限和内容状态；删除操作还要区分作者删除、管理员处理和系统下线。对于评论、关注等高频数据，返回结构应避免一次加载全部关联内容，以免造成不必要的查询和传输。

如果网站包含审核机制，接口还应区分“用户提交成功”和“内容公开可见”这两个结果。前者表示数据已被系统接收，后者则取决于审核状态，不能把两者混为一个布尔字段。

SaaS 应用型网站：先确定组织、角色和资源边界

项目管理、客户管理、财务协作和在线设计工具，通常属于 SaaS 应用型网站。它们的页面可能仍然通过浏览器访问，但核心价值是让用户完成持续的业务操作，而不是阅读内容。

此类系统应先确定用户属于哪个组织或工作区，再定义资源归属关系。例如一个任务属于某个项目，项目属于某个工作区，成员能否查看和修改任务取决于角色与权限。接口返回数据时，不仅要判断用户是否登录，还要检查资源是否属于当前组织，以及当前角色是否具备操作权限。

如果系统支持多组织或多租户，接口契约应明确组织标识的来源、资源隔离规则和管理员权限。不能只在前端隐藏按钮来实现权限控制，服务端仍需对每次读取、创建、修改和删除进行校验。

前后端分离不是独立业务类型，而是一种实现方式

“前后端分离”“单页应用”“服务端渲染”和“接口驱动”描述的是技术架构，不等于网站的业务类型。官网可以采用服务端渲染，商城可以采用单页应用，内容平台也可以通过接口向多个终端提供数据。

选择实现方式时，应结合内容更新频率、首屏访问、搜索需求、交互复杂度和团队技术栈。页面是否需要实时更新、是否存在登录后的复杂操作，往往比“网站看起来属于哪一类”更能决定接口数量和渲染方案。

从网站类型落到可执行的接口契约

完成类型判断后，可以沿着“核心动作—业务资源—状态规则—接口输入输出”的顺序细化需求。以内容站为例，核心动作是浏览和发布，资源是内容，状态包括草稿与已发布，接口则需要覆盖内容列表、内容详情、创建内容和修改状态等能力。以商城为例，核心动作是购买，资源会扩展为商品、购物车和订单，接口边界也随之变化。

1. 确定资源：把页面中的核心对象转换为可管理的数据实体，例如内容、商品、订单、项目或任务。
2. 确定动作：区分查询、创建、修改、删除、提交、审核和状态变更，不把所有操作合并成一个接口。
3. 确定契约：约定请求参数、返回字段、认证方式、错误结构、分页规则和状态码。
4. 验证闭环：用真实业务场景检查接口是否能支持页面操作，并验证权限、异常和重复提交情况。

接口文档应以实际后端能力为准，明确哪些接口已经实现、哪些仍需开发。前端可以先根据约定的字段制作页面，但不能将示例字段当成已存在的服务能力。这样既能回答网站有哪些类型，也能把类型判断落实为可开发、可联调和可验收的实现方案。