企业官网建设流程全解析

最近连着有好几个师弟师妹拿同一个题目来问我：“基于PHP的新闻管理系统设计与实现”，而且不约而同地都在标题后面带了“vue”。他们卡住的点几乎一样：网上能搜到的旧教程大多是PHP直接渲染HTML，后端把整个页面拼好丢给浏览器，跟标题里的Vue完全是两条路线，完全不知道Vue该出现在哪个环节、跟PHP怎么配合。

这篇文章我就从这个点切入，把我自己平时做这类项目时的完整思路从头捋一遍：为什么选PHP+Vue这套组合、数据库表怎么设计、后端API怎么写得干净、前端路由和状态怎么拆、最后部署上线会遇到哪些坑。内容会尽量贴合“课程设计、毕设、个人练手、小团队内部系统”这类真实场景，目标是让你照着思路能完整复现一个可用的新闻管理系统，而不是停留在“把CRUD跑通就交差”的层面。

1. 为什么是PHP+Vue：三套方案对比后我确定的前后端分离架构

先说结论：标题里既然写明了“vue”，这套系统最合理的做法就是前后端分离——PHP只负责提供JSON接口，Vue负责渲染页面和交互。这个结论不是拍脑袋，而是把三种常见方案来回比较之后得出来的。

1.1 三种常见做法的利弊拆解

我见过很多同学拿到“新闻管理系统”这个题目的第一反应，是打开PHP教程里最古老的那种写法：一个news_list.php文件里写死HTML、CSS、PHP循环，数据库查询结果直接拼进模板。这种方案我称之为“全栈单文件流”。

方案A最直观，但有一个很实际的问题：一个功能稍微全一点的新闻管理系统，至少有“前台展示、后台管理、数据接口”三块，如果全部用PHP模板渲染，你会被迫造一套自己的“模板继承”机制，做出来既不像样又难维护。方案B是在A的基础上打补丁，短期看省事，但接口和HTML片段混在一起，后面每加一个字段都要到处找拼接点。

方案C才是标题里“vue”三个字母真正落地的位置。把PHP压缩成纯接口层之后，它要做的事变得非常简单：接收参数、查询数据库、返回JSON。所有页面跳转、状态切换、列表筛选、富文本展示，全交给Vue处理。这样前端一个工程、后端一个工程，改样式不会碰到SQL，改接口不会影响页面结构。

1.2 新闻管理系统这个场景为什么适合前后端分离

很多人以为前后端分离是“大厂才需要的架构”，小项目单文件一把梭就行。这个观点我不同意，尤其是在新闻管理系统这种业务上。

新闻系统的典型使用场景是两端：一边是普通访客看新闻列表、点进详情、按分类筛选；另一边是编辑或管理员登录后台、发布新闻、修改内容、下架过期文章。这两个角色的界面差异很大，访客端要美观流畅，管理端要表格清晰、表单顺手。如果用PHP模板渲染，等于同一套后端逻辑要维护两套模板，每个新功能要同时改业务代码和两处视图，工作量直接翻倍。

前后端分离反而让这种“双端”结构变得清爽：Vue这边做一个前台页面、一个后台页面，共用同一套请求封装和数据状态；PHP这边只需要把新闻的增删改查、分类读取、管理员登录这些能力做成接口，不管谁来调用都一视同仁——访客端调用列表接口，管理端调用更新接口，将来做个移动端小程序，照样调这批接口。

这样还有一个隐形好处：接口即文档。前后端分离之后，你的系统必然要先定义接口格式，这就逼着你把“这个接口接收什么参数、返回什么结构、失败时怎么提示”想清楚。这个习惯带到工作中非常值钱。

1.3 版本与工具链选型

确定架构之后，工具链也要定准，否则后面会不断踩版本的坑。我的建议是：

• PHP版本：至少 PHP 7.4，如果是新项目直接用 PHP 8.x。PHP 8 有更严格的类型声明和更好的性能，常见的集成环境默认也基本都是8了。需要注意：老教程里mysql_*函数在 PHP 7 就已经删干净了，一定用 PDO 或mysqli扩展。
• MySQL：5.7 或 8.0 都行，字符集必须用utf8mb4，否则存不了emoji和生僻字。这一点在新闻内容里很常见，标题里出现特殊符号是常有的事。
• PHP端结构：不用重型框架也没关系，但目录要清晰。我给自己的项目定的结构很简单：public/index.php做入口、app/Controllers放控制器、app/Models放数据访问、config/database.php放配置。如果你愿意用主流的轻量框架也可以，但核心业务逻辑自己手写一遍，后面查问题会很有底气。
• 前端：Vue按当前主流版本的组合式API来写，组件和逻辑可以按单文件组件组织。搬运思路时不需要纠结脚手架品牌，理解“组件、路由、状态”三个概念即可。

2. 先定数据表再写代码：新闻系统的表结构与接口约定

很多新手一上来就写代码，写到一半发现“这个字段没存”“那个状态没法表达”，被迫回头改表。我的习惯是先花一两个小时把表结构和接口约定定死，再动手写任何一行REST接口和Vue页面。这一步省下的返工时间远超你的想象。

2.1 三张核心表：news、category、admin

新闻管理系统的核心数据无非三类：新闻本身、新闻分类、管理员账号。我用一份简化但完整的建表SQL来说明字段设计逻辑：

CREATE TABLE `category` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `name` VARCHAR(50) NOT NULL COMMENT '分类名', `sort_order` INT NOT NULL DEFAULT 0 COMMENT '排序值，越小越靠前', `created_at` DATETIME NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `news` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `category_id` INT UNSIGNED NOT NULL COMMENT '所属分类', `title` VARCHAR(255) NOT NULL COMMENT '新闻标题', `summary` VARCHAR(500) NOT NULL DEFAULT '' COMMENT '摘要，列表页展示', `content` MEDIUMTEXT NOT NULL COMMENT '正文，含HTML', `cover_url` VARCHAR(500) NOT NULL DEFAULT '' COMMENT '封面图地址', `author` VARCHAR(50) NOT NULL DEFAULT '' COMMENT '作者或来源', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0草稿 1已发布 2下架', `is_top` TINYINT NOT NULL DEFAULT 0 COMMENT '是否置顶 0否 1是', `view_count` INT UNSIGNED NOT NULL DEFAULT 0 COMMENT '浏览量', `publish_time` DATETIME NOT NULL COMMENT '计划发布时间', `created_at` DATETIME NOT NULL, `updated_at` DATETIME NOT NULL, KEY `idx_category_status` (`category_id`, `status`), KEY `idx_publish_time` (`publish_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `admin` ( `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL, `password_hash` VARCHAR(255) NOT NULL COMMENT '只存哈希，不存明文', `role` TINYINT NOT NULL DEFAULT 1 COMMENT '1编辑 2管理员', `last_login_at` DATETIME DEFAULT NULL, `created_at` DATETIME NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

逐个字段解释几个容易被忽略的设计决策：

• news.content用MEDIUMTEXT，因为新闻正文里包含富文本HTML，一篇长文几万字节很正常，VARCHAR根本放不下。
• admin.password_hash只存哈希。常见错误是存明文密码，一旦数据库泄露等于全部账号裸奔。用password_hash()函数生成，验证时用password_verify()。
• news.status用TINYINT而不是字符串，便于查询和索引。草稿、已发布、下架三个状态统一用数字表达。
• publish_time单独建字段且建索引，是为了后面做“定时发布”和“按时间排序”时性能不崩。列表页默认按这个时间倒序取，索引能大幅加快排序。

2.2 标签、置顶、定时发布这些细节怎么落表

新闻系统往往要支持“标签”功能，比如一篇科技新闻可以打上“AI”“硬件”两个标签。标签的实现有两种路线：一种是建tag表和news_tag关联表；另一种是在news表里加一个tags字段直接存JSON字符串。

我的建议是：如果标签只是“展示用”，不打算按标签聚合出独立列表页，就用JSON字段存，查出来直接解析就行；如果后面要做“点击某个标签查看所有相关新闻”，那就必须建关联表，否则SQL里到处是LIKE '%"AI"%'，又慢又容易误匹配。课程设计和普通内部系统通常选第一种就够用，架构上少两张表，省很多事。

置顶逻辑和定时发布也值得注意。置顶不是一个独立的“状态”，而是一个排序条件——列表查询时先按is_top DESC，再按publish_time DESC，这样置顶文章自然排在最前面，普通文章按时间倒序。定时发布则完全靠一个字段实现：编辑保存时如果选了“定时发布”，就把status设为1（已发布状态）、publish_time设为未来的时间。列表查询统一加一个条件：

WHERE status = 1 AND publish_time <= NOW()

未来的文章虽然状态是“已发布”，但查询时不会出现，到点之后自动“上线”，一份代码同时覆盖普通发布和定时发布，不需要额外跑定时任务。

2.3 后端接口的返回约定与错误码

表定了，接口约定也该定。前后端分离最忌讳的是每个接口返回结构不一样——有的直接返回数组，有的包一层{data: ...}，有的错误提示放在message里，有的放在error里。前端写起来就得每个页面单独判断，非常痛苦。

我所有项目的接口都固定统一为一个JSON结构：

{ "code": 0, "msg": "success", "data": {} }

• code=0表示成功，非0表示失败。
• msg是人类可读的提示信息，前端可以弹出来给用户看。
• data是真正的业务数据。列表接口固定为{ "list": [], "total": 0, "page": 1, "size": 10 }。

错误码不要随手乱编。我给新闻系统定的错误码就几组：1参数错误、2未登录或登录过期、3无权限、4资源不存在、5服务器内部错误。前端只要统一处理这几类，就能做到“接口报错时给用户一个清晰友好的提示”，而不是控制台里一行红色报错。

3. PHP后端实现：一个干净的API层是怎么搭出来的

接口约定想清楚之后，PHP端的实现其实是很机械的活。这一步的目标是“干净”——代码结构让任何一个接手的人能一眼看懂，而不是一个文件写八百行。

3.1 入口文件、路由分发与公共响应头

我习惯用单入口模式：所有请求都进入index.php，由它解析路由参数、调用对应控制器、返回JSON响应。一个极简的入口长这样：

<?php // public/index.php header('Content-Type: application/json; charset=utf-8'); $route = $_GET['r'] ?? 'news/list'; $parts = explode('/', $route); $controllerName = ucfirst($parts[0]) . 'Controller'; $action = $parts[1] ?? 'index'; require_once __DIR__ . '/../app/Controllers/' . $controllerName . '.php'; try { $controller = new $controllerName(); if (!method_exists($controller, $action)) { throw new RuntimeException('接口不存在', 404); } $result = $controller->$action(); echo json_encode(['code' => 0, 'msg' => 'success', 'data' => $result]); } catch (Exception $e) { http_response_code($e->getCode() >= 400 ? $e->getCode() : 500); echo json_encode([ 'code' => $e->getCode() === 0 ? 500 : $e->getCode(), 'msg' => $e->getMessage(), 'data' => null ]); }

几个关键点：

• 入口文件设置全局的Content-Type: application/json; charset=utf-8，保证中文不乱码。
• 控制器内的业务代码只需要正常返回数据，异常统一交给入口文件的全局捕获，不用每个方法写一堆try catch。
• 路由参数r因为是用户在URL里传的，控制器名和动作名在解析后需要做白名单校验，至少禁止../这种路径穿越写法。安全起见，可以在路由解析处限定允许出现的控制器列表。

3.2 列表接口：参数解析、分页SQL与防注入

新闻列表接口是最常被调用的接口，也是参数处理最容易出错的接口。设计上要接收这几类参数：page页码、size每页数量、category_id分类筛选、keyword关键词搜索、sort排序方式。

<?php // app/Controllers/NewsController.php 片段 public function list() { $page = max(1, intval($_GET['page'] ?? 1)); $size = min(50, max(1, intval($_GET['size'] ?? 10))); $categoryId = intval($_GET['category_id'] ?? 0); $keyword = trim($_GET['keyword'] ?? ''); $where = ['status = 1 AND publish_time <= NOW()']; $params = []; if ($categoryId > 0) { $where[] = 'category_id = ?'; $params[] = $categoryId; } if ($keyword !== '') { $where[] = '(title LIKE ? OR summary LIKE ?)'; $like = '%' . $keyword . '%'; $params[] = $like; $params[] = $like; } $whereSql = implode(' AND ', $where); $pdo = getDb(); // 查询总数 $stmt = $pdo->prepare("SELECT COUNT(*) FROM news WHERE $whereSql"); $stmt->execute($params); $total = (int)$stmt->fetchColumn(); // 查询当前页数据 $offset = ($page - 1) * $size; $sql = "SELECT id, category_id, title, summary, cover_url, author, view_count, publish_time FROM news WHERE $whereSql ORDER BY is_top DESC, publish_time DESC LIMIT $size OFFSET $offset"; $stmt = $pdo->prepare($sql); $stmt->execute($params); $list = $stmt->fetchAll(PDO::FETCH_ASSOC); return ['list' => $list, 'total' => $total, 'page' => $page, 'size' => $size]; }

这段话里藏着三个实操要点，新手很容易忽略：

第一，SQL注入的防护核心是“参数绑定”。$whereSql里全部是固定字符串或数字字段名，用户传入的keyword、category_id全部通过?占位符交给PDO处理，绝不直接拼进SQL。你可以在任何教程里看到“不要拼接SQL”，但真正理解是在自己拼接出第一次注入漏洞之后。

第二，分页大小必须设上限。size参数用min(50, ...)封顶，防止有人传size=100000直接把整张表打出来拖垮数据库。这类小细节是区分“能用”和“好用”的分水岭。

第三，排序字段要做白名单。如果允许用户传sort=view_count或sort=publish_time，一定要在代码里准备一个允许排序的字段映射表，而不是直接把参数拼到ORDER BY后面。否则字典序注入、盲注都是从这个口子漏进来的。

3.3 详情接口与浏览量统计

详情接口按id取单条数据，同时为列表页的展示补充分类名称：

public function detail() { $id = intval($_GET['id'] ?? 0); if ($id <= 0) { throw new RuntimeException('参数错误', 1); } $pdo = getDb(); $stmt = $pdo->prepare( "SELECT n.*, c.name AS category_name FROM news n LEFT JOIN category c ON n.category_id = c.id WHERE n.id = ? AND n.status = 1 AND n.publish_time <= NOW()" ); $stmt->execute([$id]); $news = $stmt->fetch(PDO::FETCH_ASSOC); if (!$news) { throw new RuntimeException('新闻不存在或已下架', 4); } // 浏览量 +1 $pdo->prepare("UPDATE news SET view_count = view_count + 1 WHERE id = ?") ->execute([$id]); return $news; }

浏览量更新的实现是个容易掉坑的地方。常见错误写法是先SELECT view_count，在PHP里加1，再UPDATE回去。两个请求同时进来时，会互相覆盖，计数凭空少掉。数据库自增表达式SET view_count = view_count + 1是原子操作，多个并发请求各加各的，不丢数据。

这个接口还有一个隐藏设计：我在查询条件里同时限制了status = 1和publish_time <= NOW()，这样即使有人拿着一个“定时发布但还没到时间”的文章ID来猜，接口也会返回“不存在”，信息不会提前泄露。

4. Vue前端搭建：路由、请求封装与新闻页面组件拆分

后端API层就绪后，前端的工作就是把这些JSON数据变成用户能看的页面。这个环节的难点不在“写一个页面”，而在于组件的拆分和请求的封装——拆得好，几百行的系统你维护起来也不累；拆不好，三个页面就够你改到崩溃。

4.1 前端目录结构与路由设计

前端工程我会按“页面+组件+请求+工具”四个维度来组织，类似这样：

src/ api/ # 接口请求函数，每个模块一个文件 components/ # 公共组件：分页、筛选栏、新闻卡片 router/ # 路由配置 views/ # 页面：Home、List、Detail、Admin、Login utils/ # 工具函数 App.vue main.js

路由设计上，新闻系统至少要这几个页面：

这里要特别提醒：详情页的路由参数不要用query传，要用路径参数/detail/:id。理由很简单，访客会把详情页链接分享给别人，路径带ID的URL显得干净，也更符合人们对“一篇文章一个地址”的预期。

4.2 axios请求封装：BaseURL、拦截器与统一提示

前端所有请求必须通过同一个封装实例发出，不要在业务组件里到处fetch(‘http://...’)。否则后端接口域名一换，你得把所有组件翻一遍。

// src/api/request.js import axios from 'axios' const request = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL || '/api', timeout: 8000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('admin_token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) request.interceptors.response.use( response => { const res = response.data if (res.code !== 0) { // 统一错误提示，例如调用 UI 库的 message 组件 showError(res.msg) return Promise.reject(new Error(res.msg)) } return res.data }, error => { if (error.response && error.response.status === 404) { showError('数据不存在') } else { showError('网络异常，请稍后重试') } return Promise.reject(error) } ) export default request

响应拦截器里做统一错误处理的收益是巨大的：业务代码里只需要关心成功的数据，失败情况永远只有一个出口。以后想加“401自动跳登录页”，也只改拦截器这一处。

环境变量也建议一步到位：开发环境VITE_API_BASE_URL指向本地后端地址，生产环境用相对路径/api，配合Nginx反代同源部署。这样代码不需要因为部署环境不同而改动。

4.3 列表页与详情页：联动、分页与富文本渲染

列表页的核心是“筛选条件”和“列表数据”的联动。我会用一个响应式对象保存筛选条件，条件变化时重新请求：

const query = reactive({ page: 1, size: 10, category_id: 0, keyword: '' }) async function fetchList() { loading.value = true try { const data = await getNewsList({ ...query }) newsList.value = data.list total.value = data.total } finally { loading.value = false } } function handleSearch() { query.page = 1 fetchList() }

这里有个很容易忽略的交互细节：点击搜索时，页码必须先重置为1。否则你在第3页搜索关键词，结果可能返回一个空的第3页，用户一脸懵。同理，切换分类后也要重置页码。

新闻列表的每一项通常只展示标题、摘要、封面、时间和浏览量，点击跳转详情页。跳转时用路由的push带上文章ID，详情页从路由参数里取ID，再请求详情接口。

详情页里的富文本渲染是新闻系统特有的环节。后端存的content字段是一段HTML，Vue里直接渲染可以用v-html，但千万不要直接无脑用——它会执行HTML里的脚本，带来存储型XSS风险。一个看起来人畜无害的编辑器子菜单项，可能让任何访客都成为攻击入口。正确思路是后端入库前做白名单过滤，前端渲染前再做一道过滤。至少要把<script>标签、onclick、onerror这类事件属性全都剥掉。哪怕只是做个课程设计，我也建议你养成这个习惯，因为代码被复用到别处时，安全意识是最容易继承的资产。

5. 把这个系统跑通并在公网展示：部署阶段的三个大坑

本地开发跑得好好的系统，一部署到线上就各种状况。我把新闻管理系统部署环节最常遇到的三个坑单独拎出来讲，它们每个都是我真实踩过的。

5.1 开发环境跨域：代理方案与后端CORS头

本地开发时Vue默认跑在一个端口，PHP后端跑在另一个端口，浏览器直接请求会触发跨域拦截。两个解决思路都可用：

方案一，后端加CORS响应头。在PHP入口文件里加：

header('Access-Control-Allow-Origin: http://localhost:5173'); header('Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS'); header('Access-Control-Allow-Headers: Content-Type, Authorization'); header('Access-Control-Allow-Credentials: true');

如果前端请求带Authorization头，必须Allow-Headers里加上，否则预检请求过不了。开发阶段Allow-Origin建议精确写前端地址，不要图省事用*，因为*与Allow-Credentials: true不能同时用。

方案二，用前端脚手架的开发代理。让前端把请求发到同源地址，由开发服务器转发到后端。这种方案的好处是浏览器永远只跟同一个域名打交道，完全避免跨域；坏处是只覆盖开发环境，线上还得靠服务器配置。

我的建议是：小项目直接用后端CORS头最省事，开发和生产统一；如果你的团队有专门的运维规范，再考虑代理方案。

5.2 富文本XSS：前端过滤只是第一层

刚才在详情页提到了XSS，部署阶段这件事会被放大，因为攻击者访问的是公网地址，你没法再拿“本地安全”安慰自己。

严谨的做法有两道工序：第一道在后端，保存新闻内容时用白名单策略清洗一遍HTML。所谓白名单，就是只允许保留固定的标签（比如<p>、<a>、<img>、<strong>、<h1>~<h6>）和固定的属性（比如href、src），其余标签和事件属性一律删除。第二道在前端，展示前再做一次过滤，双保险。如果项目准备长期维护，可以直接引入成熟的富文本净化类库，它们的正则和解析器比你自己写的可靠得多。

有一个边界情况容易被忽略：标签对属性的处理。有的清洗逻辑只删<script>标签，但攻击者可以构造<img src=x onerror=alert(1)>，事件属性照样能执行脚本。所以“去掉事件属性、只保留基础属性”是必须的，不能只删标签。

5.3 Nginx伪静态与PHP-FPM路径重写

部署阶段最让人崩溃的问题之一就是刷新404。这个问题的根源是前端路由用了HTML5 History模式，浏览器访问/detail/3时，服务器上根本没有这个文件，所以返回404。解决办法是Nginx做try_files回退：

location / { try_files $uri $uri/ /index.html; }

意思是：请求的路径如果找不到对应文件，就统一返回index.html，由前端路由接管解析。

后端PHP如果用了我前面写的pathinfo风格路由（index.php?r=news/list），为了美观也可以在Nginx里把/news/list这类路径重写到index.php：

location /api { rewrite ^/api/(.*)$ /index.php?r=$1 last; }

但更稳妥地，在开发阶段直接用index.php?r=...访问，先确保功能正常，再折腾伪静态。否则路由美化没做对，接口全是404，排查起来要绕很大一圈。

部署后还要检查一件事：数据库连接和字符集。数据库连接字符串里务必带charset=utf8mb4，PDO连接时也要设置exec('SET NAMES utf8mb4')，否则接口返回的中文在部分客户端里会变成乱码。还有时区，PHP里date_default_timezone_set('Asia/Shanghai')这一行建议入口文件就写上，否则publish_time按服务器默认时区存储，发布时间的展示和判断可能差好几个小时。

我个人做过不少新闻媒体类的小系统，回头来看，这个“PHP API + Vue前端”的结构是性价比最高的做法。它不需要很重的架构设计，却把前后端分离、接口约定、数据建模、安全防护这几项最基础也最重要的工程能力都练了一遍。总有人问我“这个题能不能直接套个模板交差”，我的回答通常是：如果只想交差，套模板当然可以；但如果你愿意花一周把这个系统里的每个环节都自己敲一遍，下次面试官问你“讲一个你最熟的项目”的时候，你说话的语气都会不一样。

最后再分享一个小技巧：管理端的新闻列表，第一版就把“操作日志”顺手加进去。谁在什么时候改了什么字段，全部记录下来。当时可能觉得多此一举，等项目跑起来之后你才会发现，排错时最省力的不是看代码，而是看日志表里那几行记录。