企业官网建设流程全解析

接手这份“任务书基于LAMP技术梦幻水晶婚纱摄影网站系统”的时候，我第一反应是：这又是一道“功能堆叠”式的作业题。但真正把任务书里的每个词拆开看，才发现它其实覆盖了一个Web开发全流程里最核心的环节——从需求分析、界面设计、数据库建模，到后台管理、前端交互、部署上线，几乎每个阶段都有值得展开说的东西。而且LAMP这套技术栈放在婚纱摄影这个具体业务场景里，有不少细节是教科书上不会写、但实际开发中一定会遇到的。这篇博文我就按自己实操时的思路，完整走一遍这个系统的搭建过程，把我踩过的坑、做过的取舍一起写清楚，希望能给准备做类似项目的朋友一些参考。

1. 任务书拆解：婚纱摄影网站的需求到底落在哪里

先别急着写代码。任务书类型的项目，最忌讳的就是拿到题目就开撸。因为任务书里往往只有一句话概括，比如“基于LAMP技术梦幻水晶婚纱摄影网站系统”，这句话的信息量很大，但没有一句是废话，每一个修饰词都指向明确的需求点。第一步要做的，是把它拆成可落地的功能清单和业务流程。

1.1 拆解关键词，得到功能模块

我把标题拆成了三层来理解。

第一层是“婚纱摄影”。这是业务核心，决定了网站的内容形态。婚纱摄影公司要展示什么？无非是客片和样片、套系价格、摄影师团队、拍摄场地、客户评价、在线预约和留言咨询。其中“作品展示”和“在线预约”是重头戏，因为婚纱摄影是高客单价、强决策周期长的消费，客户要先看作品、再比价格、然后才谈预约，所以网站必须在这几个环节给足信息量。

第二层是“网站系统”。这说明它不是纯静态页面，而是要有一个完整的后台管理系统。前台给访客看，后台给运营人员用，包括作品上传与管理、套系维护、预约单处理、评论管理、基础设置修改等。也就是说，这个项目天然包含前后台两条线，工作量和难度都比单页面的企业站高出不少。

第三层是“梦幻水晶”和“LAMP技术”。前者是视觉风格方向，典型的女性消费场景审美，设计基调可以往透亮、轻盈、浪漫那边靠；后者是技术选型约束，Linux + Apache + MySQL + PHP，说明这个项目偏重经典Web开发路线的考察，不依赖复杂框架，但要求你把全栈基本功打扎实。

按这个拆解，我整理出来的功能模块大概如下：

1.2 用户角色与业务流程分析

功能模块列完之后，还要把业务跑一遍，看看谁在使用、操作顺序是什么。这个系统里主要有两类角色：访客和管理员。

访客的路径一般是：进入首页看轮播图和精选作品，被某个风格吸引后点进作品列表，翻几页找到喜欢的套系，然后触发预约或留言动作。管理员则每天登录后台，处理新的预约单、回复留言、更新作品内容。

关键流程是预约闭环：访客在预约页面填写姓名、电话、意向套系、期望拍摄日期，提交后数据写入数据库，后台看到新预约单后进行状态管理（例如设置为“已联系”“已确认”“已完成”）。这个看起来简单的流程，实际开发时涉及表单验证、入库、列表展示、状态修改四个环节，是检验CRUD基本功的好题目。

1.3 任务书为什么点名LAMP技术

LAMP是非常经典的技术栈组合，到现在依然有大量中小型项目跑在上面。任务书点名LAMP，本质上是在考察几个能力：Linux服务器的基本操作、Apache的站点配置与伪静态规则、MySQL的表设计与SQL语句、PHP的业务逻辑编写与数据库交互。这套组合覆盖了Web开发最底层的知识体系，比起一上来就用全家桶框架，反而更能看出一个问题——你懂不懂HTTP请求从浏览器到服务器再到数据库然后返回的完整链路。

我采用的就是原生PHP + MySQL + Apache的方案，不引入ThinkPHP或Laravel这类重量级框架。原因后面单独说，简单讲就是：项目规模不大，框架带来的规范性和组件化收益不明显，反而原生PHP让我对每个请求的处理过程都心里有数。

2. 为什么选LAMP：被低估的技术栈搭档与四个组件的分工逻辑

很多人觉得LAMP是老古董，实际上它的稳定性和易维护性至今能打。尤其是这种带管理后台的内容展示类网站，LAMP可以说是极度匹配。下面把它四个组件的分工理一遍，这也是任务书最想看到你理解的东西。

2.1 四个组件各司其职

Linux是操作系统层，我用的是CentOS 7。它的角色是提供稳定运行环境，包括文件系统、进程管理、网络服务，这一层选熟了，后面部署会省很多事。

Apache是Web服务器层，核心职责是接收HTTP请求、解析域名和端口、把请求转交给PHP处理。配置上有几个点需要注意：虚拟主机（一个服务器跑多个站点）、目录权限（DocumentRoot和Directory节点的Options）、URL重写规则（实现伪静态）。婚纱摄影网站的图片很多，Apache处理静态文件的能力虽然谈不上性能怪兽，但配合好缓存策略完全够用。

MySQL是数据层，存放所有动态内容，包括管理员账号、作品分类、图片记录、套系价格、预约数据等。这个项目里，MySQL承担的核心任务有两个：一是通过合理的表结构存储业务数据，二是通过SQL查询支撑前台展示和后台管理的各种列表筛选。

PHP是应用层，它夹在浏览器和数据库之间：接收表单数据、做校验、拼SQL查库、把结果渲染成HTML输出。LAMP里的PHP是最能体现程序员水平的一环，因为业务逻辑都在这里。比如上传图片时的类型验证、生成缩略图、预约单号生成、分页参数计算，这些全部要靠PHP代码来实现。

2.2 原生PHP与框架之争，我的取舍理由

做这个项目时，身边的人分成了两派。一派觉得应该用ThinkPHP，理由是开发效率高、安全性有保障、代码结构清晰，以后简历也好写。另一派认为原生PHP足够，因为这个项目本质上是“作品展示 + 后台管理”，不存在特别复杂的业务关系。

我最终选了原生PHP。核心原因是：项目规模摆在那里，大概十几个核心表、几十个页面，Laravel和ThinkPHP光是初始化、配置、路由规则就要花不少时间，而且框架本身的学习成本会摊薄你对业务本身的关注。用原生PHP，文件结构完全可以自己控制，比如把公共头尾拆成单独的template文件，把数据库连接封装成公共方法，把表单验证写成一个工具函数，工程感并不比框架差多少。

安全性方面，原生PHP确实更容易写脏代码，但反过来也让每个安全点都暴露在明面上，逼着你处理。SQL注入用预处理语句，密码用password_hash加密，上传用白名单校验文件类型和扩展名，XSS通过htmlspecialchars转义输出内容。把这些基础安全问题处理到位，原生PHP的可靠程度并不低。

2.3 本地开发环境的选择与坑

开发环境我用的phpStudy，因为它在Windows下集成Apache、MySQL、PHP一键启动，对新项目起步非常友好。不过这里有个问题值得警惕：本地Windows环境和线上Linux环境存在差异，最典型的就是PHP版本。

phpStudy默认带了多个PHP版本，我选了PHP 7.4，主要是考虑到稳定性和兼容性都还合适。如果你看到某些老教程还在用mysql_connect这种函数，一定要提醒自己，那个API在PHP 7里已经彻底移除了，必须改用mysqli或PDO。我用的就是mysqli的面向对象写法，配合预处理语句，既安全又清晰。

另外还要注意一个非常容易踩的坑：本地Windows下路径分割符用的是反斜杠，Linux下正斜杠和反斜杠都能识别但习惯上是正斜杠；更重要的是Linux文件系统区分大小写，而Windows不区分。如果你在本地写代码时大小写比较随意，传到线上服务器后大概率会碰到“页面找得到但图片加载不出来”这种诡异问题。所以从第一天我就要求自己，文件名、目录名、函数命名、变量命名全部保持统一风格，避免上线前大量返工。

3. 把“梦幻水晶”翻译成代码：视觉主题的前后端实现思路

任务书里“梦幻水晶”这个词看起来是设计层面的事，但它最终是要靠前端CSS和后端数据结构共同完成的。在这个项目里，视觉风格不是孤立的，它和首页的内容组织、图片呈现方式深度绑定。

3.1 设计语言的落地方式

“梦幻水晶”给人的联想是透亮、渐变、轻盈、浪漫。对应的前端实现思路是：

• 主色调选择水晶蓝和淡紫色系，辅助色用银白和浅粉。实际取色上，我用了#4FC3F7作为主蓝、#9C6ADE作为辅助紫，背景是接近白色带一点点冷色调的#F4F8FB。
• 水晶质感最直观的表达是“玻璃拟态”（Glassmorphism），即半透明背景加模糊效果。CSS里用backdrop-filter: blur(10px)配合半透明背景rgba(255,255,255,0.6)，就能实现那种磨砂玻璃的感觉，用在导航栏和卡片上效果很明显。

/* 导航栏玻璃拟态示例 */ .glass-nav { background: rgba(255, 255, 255, 0.6); backdrop-filter: blur(10px); -webkit-backdrop-filter: blur(10px); border-bottom: 1px solid rgba(255, 255, 255, 0.4); }

• 渐变背景也很重要，可以用在页面顶部和按钮上，营造那种“光在流动”的感觉。按钮的渐变从#4FC3F7到#9C6ADE，配合轻微的圆角和阴影，视觉上非常柔和。

• 字体方面，标题用偏细的字重，正文保持清晰易读。中文字体用系统自带的微软雅黑或苹方即可，重点是字号层级拉开，不要所有内容一样大。

需要注意的是，“梦幻”不能以牺牲加载速度为代价，尤其是backdrop-filter这个属性，在低端手机上会有性能问题。我的处理是只在顶部导航和一个主视觉卡片上使用，文章列表、作品卡片这些高频元素尽量用普通背景加细边框模拟轻质感。

3.2 图片处理是婚纱网站的生命线

婚纱摄影网站，图片就是核心资产。一个作品详情页如果原图有好几兆，加载起来用户早就走了。这里必须做图片压缩和缩略图。

我使用PHP自带GD库进行处理。上传原图后，服务端自动生成中等尺寸的列表图和极小尺寸的缩略图，前台列表页用小图，点击详情再加载中等尺寸，原图则只在大图查看时使用。这样既保留了画质，又控制住了带宽消耗。

// 生成缩略图的核心思路 function createThumb($srcPath, $dstPath, $maxWidth, $maxHeight) { list($srcW, $srcH) = getimagesize($srcPath); $scale = min($maxWidth / $srcW, $maxHeight / $srcH); $newW = (int)($srcW * $scale); $newH = (int)($srcH * $scale); $srcImg = imagecreatefromjpeg($srcPath); $dstImg = imagecreatetruecolor($newW, $newH); imagecopyresampled($dstImg, $srcImg, 0, 0, 0, 0, $newW, $newH, $srcW, $srcH); imagejpeg($dstImg, $dstPath, 85); imagedestroy($srcImg); imagedestroy($dstImg); }

上传图片时的文件校验也必须在服务端做，不能光靠前端。我写了一个公共校验函数，检查三个维度：文件扩展名是否在jpg/png/webp白名单内，MIME类型是否匹配，文件大小是否超过设定的5MB上限。三个条件全部通过才允许move_uploaded_file。

图片命名我用“日期+随机字符串”的方式，例如20250603_ab12cd.jpg，避免中文文件名和重复文件名带来的各种问题。图片目录按用途分成upload/original和upload/thumb两层，程序逻辑清晰，备份也方便。

3.3 首页内容规划与数据库调用的联动

首页展示哪些内容，直接决定了数据库要写哪些查询。我的规划是：顶部轮播位放3-5张精选大片，下面依次是“套系推荐”“客片精选”“最新动态”三个区域。“套系推荐”从package表里取3个推荐套系，“客片精选”从photo表里按点击量排序取最近一个月的6张，“最新动态”则从内容表里取3条公告。

这个设计意味着前端并不是傻白甜地输出静态HTML，每个区域都要有自己的SQL循环。但问题也来了——如果首页一次性执行五六个查询，每次都连一次数据库，效率不够好看。我的做法是把数据库连接封装成单例模式，全页面复用同一个连接实例，这样数据库握手只发生一次，后续查询都走同一连接通道，对性能有明显的提升。

首页还有个容易被忽略的细节：轮播图的图片路径不要写死在HTML里，而是从数据库配置表读取。这样运营人员后续在后台替换轮播图时，只需要改配置，不用动代码。

4. 数据库设计：婚纱摄影业务最核心的表结构梳理

数据库设计是这个项目的骨架。表设计得好，后面所有查询都顺；设计得烂，写SQL的时候会想骂人。我最终设计了8张核心表，下面把最重要的几张展开说。

4.1 核心表的字段设计

photo表是这个项目里最核心的内容表。因为它承载了婚纱摄影网站最关键的资产——图片。category_id关联分类表，让作品可以按风格筛选。click_count用于统计热门作品，首页“人气推荐”就是按这个字段倒序取的。

package表也比较有讲究。套系的价格、封面图、描述都直接放表里，这没问题，但“套系包含内容”如果用单独一张表存明细，开发量和数据插入量都会增加。我选择用contents这个TEXT字段把多行内容打包进去，前台输出时按换行符拆成列表展示。在这个项目规模下，这种“冗余”是可接受的，换来的是插入和查询的简单直接。

4.2 预约表为什么需要status状态字段

appointment表可以说是整个系统里业务属性最强的一张表。婚纱摄影的预约不是提交完就结束了，后面还有线下沟通、订单确认、拍摄完成等多个环节。所以status字段是必须的，并且我给它定义了四个状态：

• 0：新提交待处理。表单刚提交进来时的默认状态。
• 1：已联系。表示工作人员已电话回访，加了微信，正在沟通需求。
• 2：已确认。客户确认拍摄日期和套系，准备拍摄。
• 3：已完成。拍摄已经结束，订单走完。

有了状态字段，后台列表页就可以按“新预约”优先排列，管理员一登录看到的就是最需要处理的数据，而不用从一堆记录里面翻。状态流转也很简单，后台列表提供一个下拉框或按钮组，点击就把状态值更新掉。从开发角度讲就是一个UPDATE语句的事，但从业务角度讲，它让后台具备了客户关系管理的雏形。

另外，预约表里我特意存了一个address字段，用于记录婚拍地点或客户所在城市。这个字段看起来不起眼，但对于拍摄团队安排档期很有帮助。如果你希望项目有更多可展示的亮点，可以在预约表上再做一层统计：查询某个月的预约量、各状态的数量分布，做成简单的数据看板，工作量不大，但汇报时效果很好。

4.3 字符集、关联删除与时间字段的细节

数据库这块有几个细节值得专门提醒。

第一是字符集。建库的时候一定要使用utf8mb4而不是utf8，因为utf8mb4才是真正完整的UTF-8支持。虽然在这个项目里可能用不上emoji，但缓存的评论内容万一有人发了emoji，用utf8会出现无法存储的问题。同时，数据库连接串也要显式设置字符集：

mysqli_set_charset($conn, 'utf8mb4');

如果不设置这一步，即使数据库表是utf8mb4，PHP从数据库取出的数据依然可能因为连接层默认字符集不对而出现乱码。

第二是外键和关联删除。任务书项目里我建议外键约束要适度使用。category表和photo表之间的级联删除可以开启，这样后台删除一个分类时，自动把该分类下的照片一并删除，避免出现“孤儿数据”。但另外一些关联，比如预约表关联套系，就不要开启级联删除了，因为客户预约信息属于业务记录，即使套系下架了，历史预约数据也必须保留。

第三是时间字段类型。created_at用DATETIME已经够用，不需要追求TIMESTAMP或int时间戳。在前台显示时直接取出来格式化就行。这里要特别注意一个坑：服务器默认时区是UTC，不加配置的话，你存进去的时间会比北京时间少8小时。解决方式是在PHP连接数据库后执行一句：

SET time_zone = '+08:00';

或者在PHP代码里用date_default_timezone_set('Asia/Shanghai')统一时间源。这个坑如果没注意，会精准地体现在“预约时间显示不对”这种问题上。

5. 后台与预约流程：最容易出问题又最能体现诚意的部分

后台管理系统是这个任务书项目的分水岭。很多人会把前台做得花团锦簇，但后台一塌糊涂。实际上，后台才是评判一个开发真功夫的地方，因为它要处理的业务流程、权限控制、数据交互远比前台复杂。

5.1 登录安全：从密码存储到会话管理

管理员的登录安全我做了三层保障。

第一层是密码存储。绝不使用明文密码，也不使用简单MD5。PHP里直接用password_hash函数做加盐哈希，校验时用password_verify。这样做的好处是哈希算法内部自动加盐、自动选择算法，你不需要自己设计加盐逻辑，出错的概率降到最低。

// 注册时存密码 $hashed = password_hash($password, PASSWORD_DEFAULT); // 登录时验证 if (password_verify($inputPwd, $row['password_hash'])) { // 密码正确 }

第二层是登录态管理。登录成功后把管理员id和username存进$_SESSION，后台所有页面做一个公共的权限检查函数，未登录就跳转回登录页。同时给Session设置合理的过期时间，防止用户长时间不操作导致会话泄露风险。

第三层是登录验证码。这个表单项虽然烦人，但对防止暴力破解很有效。我用GD库画了一个简单的数字验证码，流程是：生成随机数字串存入Session，输出图片；提交时对比用户输入和Session值。画验证码的代码不复杂，核心思路是先建画布、填充颜色，然后把数字写到图片上，再加一些干扰线。

// 验证码生成核心代码（思路版） $_SESSION['captcha'] = rand(1000, 9999); $im = imagecreatetruecolor(110, 38); // 填充背景、绘制干扰线、写入数字 imagejpeg($im);

5.2 作品管理：完整发布流程

作品管理涉及“上传原图—生成缩略图—填写标题和分类—写入数据库”四个步骤。这几个步骤有一个顺序容易出错：必须先移动上传文件，然后再做后续处理，否则如果缩略图生成失败，原文件都丢了。我的代码是先确保上传文件成功move到upload/original目录，再调用缩略图函数生成upload/thumb下的文件，最后把两个路径和标题、分类ID一起写入数据库。

后台作品列表页的分页功能也值得好好写。因为它是Site后端的一个典型功能点。分页核心在于LIMIT offset, count的计算。当前页数减1乘每页条数就是offset。分页HTML带上页码参数，点击翻页跳转到对应页码。

这里有一个很容易忽略的点：分页链接要处理好当前搜索条件。假设你正在按分类ID=3筛选作品，翻到第二页时，URL里除了page参数，还必须保留category_id=3这个参数，否则翻页后就丢失筛选条件了。我用一个公共函数把已有的GET参数拼接上去，再追加page参数，实用又省心。

5.3 预约管理：从表单提交到状态流转

前台预约表单要做完整的字段校验：姓名非空、手机号格式正确、预约日期不能是过去日期、套系选择有效。服务端校验尤其重要，因为前台JavaScript校验是可以被绕过的。我写了一个validateAppointment函数，把所有规则集中到一个方法里，返回错误信息数组，任何一项不通过就回显错误。

预约提交后的处理流程是：写入数据库status默认为0，然后跳转到一个预约成功页面，提示工作人员会在24小时内联系。这里没有做邮件或短信通知，因为那些涉及第三方服务对接，对任务书项目来说性价比不高。但我加了一个很实用的功能：后台导航栏显示“待处理预约”的数字角标，通过一句COUNT查询算出status=0的预约数量。管理员每次进入后台第一眼就能看到有没有新预约，体验比翻列表好得多。

状态流转就是在列表页提供“标记为已联系”“标记为已确认”按钮，点击后执行UPDATE语句更新status。为了让操作有反馈，每次更新后重定向回列表页并且在URL里带一个success参数，页面显示一句“状态更新成功”。

5.4 几个高频Bug和修复方案

整个项目写下来，有几个Bug属于“十个人里九个会遇到”的类型，把排查思路记录一下。

第一个是中文乱码。症状是前台页面显示正常，但后台提交的中文数据变成乱码。排查思路从三层入手：页面声明meta charset="utf-8"、数据库连接设置utf8mb4、数据库表和字段的字符集确认无误。如果这三层都对了，还有一个隐蔽位置——文件本身的编码格式。用记事本编辑过PHP文件的话，文件可能会被存成GBK或带BOM的UTF-8，也会出现乱码。我全程用VS Code打开并确保右下角是“UTF-8”，从根源上规避了这个问题。

第二个是图片上传失败。症状是点击上传后提示成功，但目标目录里找不到文件。最常见的原因是目录没有写权限。Linux下需要给upload目录设置权限，Windows本地一般没这个问题。

chmod -R 755 /var/www/html/upload

第三个是上传大图片提示超限。PHP默认的上传限制通常是2MB，实际拍摄的婚纱照动不动就5-8MB。修改方式有二：在php.ini里调整upload_max_filesize和post_max_size，或者在项目入口文件用ini_set进行运行时设置。注意post_max_size必须大于upload_max_filesize，否则文件会直接静默丢失。

6. 部署上线与性能调优：从本地写到线上之后的事

本地开发完只是万里长征走了一半，真正考验的是部署到线上Linux服务器之后能不能稳。很多任务书项目本地一切正常，一上线就各种问题，核心原因就是环境差异。

6.1 服务器环境与Apache虚拟主机配置

服务器我用的阿里云轻量应用服务器，系统选的CentOS 7。软件环境可以一键安装LNMP或LAMP合集，但我更建议手动安装关键组件，因为一键脚本有时候会默认开启一些用不上的模块，反而增加安全风险。

Apache配置里，最关键的是虚拟主机。一个服务器可以跑多个网站，虚拟主机就是让Apache根据域名把请求分流到不同目录。配置在/etc/httpd/conf.d/下新建一个conf文件：

<VirtualHost *:80> ServerName www.example.com DocumentRoot /var/www/html/project <Directory /var/www/html/project> Options FollowSymLinks AllowOverride All Require all granted </Directory> </VirtualHost>

AllowOverride All这个配置对应的是Apache的URL重写能力。项目如果需要用到伪静态，或者把index.php?a=1&b=2这种参数变成更友好的路径，就能在项目目录下放一个.htaccess文件来写重写规则。

6.2 上线改造清单

代码从本地传到线上，不是复制粘贴就完事的，至少要做以下调整：

• 数据库导入。用phpMyAdmin或命令行导入SQL文件，导入后注意检查表的字符集是否正确，不要变成latin1。
• 配置文件分离。我在项目根目录放了一个config.local.php，里面写本地的数据库账号密码；线上则是config.online.php。公共的config.php根据当前环境判断加载哪个，用常量DB_HOST、DB_USER、DB_PASS区分。一个小技巧是判断$_SERVER['SERVER_NAME']，是localhost就走本地配置，否则走线上配置。
• 图片权限与目录。上传目录必须确保Apache有写入权限，否则后台传图会失败。
• Linux下的路径大小写。这个之前说过，本地Windows不区分大小写，线上Linux区分。上线前我写了个简单脚本扫描所有图片引用路径，确保和实际文件一致。

6.3 性能与安全调优

网站部署完成后，有几个性能和安全优化值得做。图片压缩刚才已经说过，这是最大的性能优化点。除图片外，MySQL查询优化也不能忽视。这个项目数据量不大，慢查询几乎不会出现，但仍然建议在MySQL配置里开启慢查询日志，万一以后数据涨上去了，能第一时间发现是哪些SQL拖慢了速度。

安全方面，重点做了四件事：

• Apache配置里禁用目录浏览，防止用户直接访问upload目录看到所有文件列表。配置为Options -Indexes。
• 修改phpMyAdmin的访问路径并设置访问密码，避免数据库管理工具被扫描工具发现暴力破解。
• 给上传目录设置执行权限为755且不允许执行PHP脚本，即使有人上传了恶意脚本也无法运行。做法是在upload目录下放一个.htaccess：

php_flag engine off

• 备份策略：数据库每天凌晨自动备份，web目录每周打包一次。用了最简单的crontab + mysqldump组合：

0 2 * * * mysqldump -u root -p密码 project_db > /backup/db_$(date +\%Y\%m\%d).sql

6.4 缓存与伪静态的进一步思路

到这个阶段，网站基本可以稳定上线了。如果还想继续优化，可以做两件事。

第一是Apache的mod_pagespeed或简单浏览器缓存配置。在.htaccess里给图片、CSS、JS设置缓存时间，减少重复请求带来的带宽压力。对于婚纱摄影这种图片密集型网站，效果非常明显。

第二是URL伪静态。原本作品详情页可能是photo.php?id=12，通过.htaccess重写为photo-12.html。伪静态的代码在Apache里通常是：

RewriteEngine On RewriteRule ^photo-([0-9]+)\.html$ photo.php?id=$1 [L]

这个规则的原理是把符合样式的URL内部转发给真实的PHP文件处理，对SEO更友好，也更容易被访客记住。不过要注意，使用伪静态后，页面上所有链接的生成规则也要统一改成新格式，否则就会出现“规则写了但页面里的链接还是老地址”的半吊子情况。

最后再分享一个小技巧

项目验收或汇报前，我习惯把整个系统的操作流程串一遍，从前台提交预约到后台状态流转，再到数据备份恢复，每个环节都录屏存证。既方便自己排查问题，也能在验收时直观展示功能，比现场临场演示稳得多。另外一个很实用的习惯是：在后台加一个“测试数据一键清空”的按钮，用TRUNCATE语句把预约、留言等业务表清空并把自增ID归零，这样交付给客户时网站是干干净净的，而我自己测试时又能放心大胆地造数据。这个功能代码量很少，但用过的人都会说香。