企业官网建设流程全解析

1. 项目整体定位与技术选型

1.1 为什么选择坭兴陶作为项目题材

拿到这个项目标题的时候，我第一反应是：这不算一个单纯的“技术demo”，而是一个有明确文化属性的非遗数字化项目。坭兴陶是广西钦州的国家地理标志产品，也是中国四大名陶之一，和宜兴紫砂、建水紫陶、荣昌陶并列。它有超过一千三百年的历史，在清代甚至被列为朝廷贡品，1915年还拿过巴拿马太平洋万国博览会的金奖。这些背景信息听起来像百科词条，但放到系统设计里，它就是内容的根基——一个文化传承系统如果没有扎实的内容做支撑，做得再花哨也只是空壳。

选择这个题材的另一个现实原因是：非遗类项目的受众正在快速年轻化。过去坭兴陶的传播主要靠线下展馆、大师工作室和传统媒体，触达范围有限。而微信小程序天然具备“轻量使用、社交传播、扫码即达”的特点，很适合做文化展示类的入口。用户不需要下载App，在微信里搜一下或者扫个码就能看到陶器介绍、工艺视频、传承人故事，这种体验比传统网站友好得多。所以这个项目的本质，是用技术手段降低文化认知门槛，让更多人先“看见”坭兴陶，再谈“喜欢”和“传承”。

1.2 微信小程序、PHP、uniapp这个技术组合到底合理吗

先说结论：这个组合放在2024年的语境下，依然是非常务实的选择，尤其适合学生项目、快速落地的小型商业项目，以及像我这样做独立开发的场景。

微信小程序作为前端载体，优势不用多说：微信生态内的流量获取成本低，分享卡片、二维码、公众号跳转这些能力都是现成的。相比原生App，小程序不用考虑应用市场审核和版本更新的繁琐流程，用户体验也更轻。

uniapp作为跨端框架，核心价值是“一套代码，多端编译”。用Vue语法写一次，可以编译到微信小程序、H5、App、支付宝小程序等平台。这个项目的场景下，虽然标题只提了微信小程序，但如果你后面想做个H5官网，或者打包成Android端应用放到应用市场，uniapp的代码几乎不用大改，只需要处理各平台的环境差异。我在实际开发中，最常用到的就是HBuilderX这个IDE，内置了代码编辑、运行、打包一整套工具链，对Vue语法和微信小程序API的兼容性都做得比较到位，对比原生小程序开发的体验，确实能省不少事。

PHP做后端，在技术圈经常被吐槽“古老”，但在这种体量的项目里，它的优势很实在：语法门槛低，开发生态成熟，ThinkPHP或Laravel框架都有现成的脚手架可以用，直接起一个API服务非常快。更重要的是，PHP项目的部署成本极低，虚拟主机或者一台轻量云服务器就能跑，不挑环境，这对预算有限的学生项目和中小型文化站点来说特别友好。加上MySQL做数据存储，整套后端技术栈完全可以支撑起“内容展示+用户管理+数据统计”这类非高并发的业务场景。

这个组合还有一个隐性优势：前端和后端的逻辑分离非常清晰。uniapp只管页面渲染和用户交互，PHP只负责提供JSON接口，两者通过HTTP协议通信。这样的架构在协作开发时特别方便——前端同学可以拿Mock数据先跑起来，后端同学可以专心写接口，互不阻塞。我自己在带实训项目时就发现，这种分离方式对于团队分工和调试排查的效率提升是立竿见影的。

2. 系统架构设计与数据库建模

2.1 前端项目结构设计：uniapp的目录划分思路

一个uniapp项目拿到手，第一件事不是写代码，而是理清目录结构。我的习惯是严格区分“页面、组件、静态资源、工具方法、配置”这几块，尤其是当项目涉及多个功能模块时，目录不清会导致后期维护非常痛苦。

下面是我在这个坭兴陶项目中使用的目录结构，可以作为参考：

├── pages/ # 页面文件 │ ├── index/ # 首页（轮播图 + 推荐陶器 + 资讯列表） │ ├── culture/ # 坭兴陶文化专题页（历史、工艺、传承人） │ ├── category/ # 陶器分类列表页 │ ├── detail/ # 陶器详情页（图文、视频、参数） │ ├── article/ # 资讯文章详情页 │ ├── user/ # 个人中心（登录、收藏、浏览记录） │ └── about/ # 关于项目页 ├── components/ # 公共组件（轮播组件、陶器卡片、评论区等） ├── static/ # 静态资源（图片、iconfont、视频封面） ├── utils/ # 工具函数（请求封装、登录鉴权、格式化） ├── store/ # 全局状态管理（Vuex或Pinia） ├── App.vue # 应用入口、全局生命周期 ├── main.js # 应用初始化 ├── manifest.json # 多端配置（小程序AppID、App打包配置等） └── pages.json # 页面路由、tabBar、导航栏配置

这里有两个容易踩坑的地方。一个是pages.json里的页面注册，每新增一个页面都要在这里登记，否则跳转会找不到页面。另一个是tabBar的配置，如果首页、文化专题、个人中心这些页面要放到底部导航上，tabBar的图标和文字需要提前准备好，而且tabBar的页面路径必须是pages数组的第一层，不能嵌套在子目录里，否则小程序编译会报错。

对于这个项目，我建议首页、分类（或文化专题）、个人中心三个tab就够了，不要贪多。tabBar超过五个不仅视觉上拥挤，而且对小程序来说，每个tabBar页面都会占用更多的内存和渲染资源，首次启动速度会变慢。

2.2 后端接口设计与数据库表结构

后端我用ThinkPHP 6作为示例，原因很简单：它保留了PHP“开箱即用”的感觉，同时又提供了控制器、模型、中间件等结构化的开发方式，配置要比手写原生PHP规范得多。接口设计上，我走的是标准的RESTful风格，所有的响应统一使用下面的JSON结构：

{ "code": 200, "message": "success", "data": {} }

前端的请求封装会优先判断code是否等于200，逻辑清晰，问题也好排查。实际项目中我碰到很多同学喜欢用HTTP状态码直接判断业务逻辑，比如登录失败返回401，参数错误返回422，虽然也说得通，但在前后端联调时，往往需要同时看HTTP状态和响应体里的业务code，很容易混淆。统一用200 + code的方式，一个问题一个判断口径，省事得多。

数据库的表设计，直接决定了后面功能开发的顺畅程度。我针对这个项目梳理了主要表结构，下面挑几张核心表出来讲：

用户表（lh_user）

openid一定要加唯一索引，这是微信登录体系的核心标识。后续实现收藏、评论、浏览记录这些功能时，都靠这个字段去关联用户维度。管理员角色建议预留，虽然小程序端可能不做管理功能，但后端接口需要判断权限，防止普通用户调用管理接口改数据。

陶器信息表（lh_pottery）

这个表是整个“器物展示”的核心，字段设计要兼顾展示需求和搜索需求。我的建议是至少包含以下几类信息：

images字段用JSON数组存储多张图片，比单独建一张图片表更轻量，适合图片数量固定且不会频繁变动的场景。view_count用来记录页面浏览量，可以在详情页加载时做自增，前期不需要做复杂的统计系统，一个字段就够用。

咨询/文章表（lh_article）

文化传承系统的内容部分，除了陶器本身，还需要有资讯、典故、工艺介绍这类文章。这张表的设计可以相对灵活：

content用mediumtext类型，可以最大存储16MB的文本内容，对于图文并茂的文章来说是足够用的。富文本内容在显示时经常会有图片大小和样式问题，处理方案我放在后面的实操章节细说。

除了这三张核心表，还要有：收藏表、评论表、轮播图表、传承人表。轮播图表虽然简单，但注意要加sort字段用于排序，前端接口按sort升序返回，这样才能控制首页轮播图的展示顺序。

3. 核心功能模块的实操实现

3.1 微信登录与用户体系搭建

微信小程序的登录流程和传统Web登录差别很大，核心是借助微信的code2Session接口换取openid。整个流程的时序大概是：

1. 前端调用uni.login()获取临时code
2. 前端把code传给后端自己的登录接口
3. 后端拿着code，加上小程序的AppID和AppSecret，请求微信接口换取openid和session_key
4. 后端查数据库，如果openid已存在就直接登录，不存在就自动注册
5. 后端生成自己的token返回给前端，后续所有请求都在header里带上token

需要注意的是，uni.login()拿到的code是一次性的，有效期大概5分钟，而且每个code只能使用一次，所以后端一定要在拿到code后尽快去换openid，不要把code存到数据库里过一会儿再用。我见过有同学把code存到Redis里做二次校验，结果过几分钟就失效，排查了半天才发现是这个原因。

后端接口代码如下：

public function login() { $code = $this->request->param('code'); $appid = config('wx.appid'); $secret = config('wx.secret'); // 调用微信接口换取openid $url = "https://api.weixin.qq.com/sns/jscode2session?appid={$appid}&secret={$secret}&js_code={$code}&grant_type=authorization_code"; $res = file_get_contents($url); $data = json_decode($res, true); if (!isset($data['openid'])) { return json(['code' => 500, 'message' => '微信登录失败', 'data' => $data]); } $user = Db::name('user')->where('openid', $data['openid'])->find(); if (!$user) { $userId = Db::name('user')->insertGetId([ 'openid' => $data['openid'], 'nickname' => '陶友' . mt_rand(1000, 9999), 'create_time' => date('Y-m-d H:i:s') ]); } else { $userId = $user['id']; } // 生成token，这里用最简单的哈希方式做演示，实际可改用JWT $token = md5($data['openid'] . time()); Db::name('user')->where('id', $userId)->update(['token' => $token]); return json(['code' => 200, 'message' => '登录成功', 'data' => ['token' => $token, 'user_id' => $userId]]); }

前端uniapp封装请求时，要把token放在header里，并且要在请求拦截器里统一处理登录失效的情况。代码大致如下：

// utils/request.js const BASE_URL = 'https://yourdomain.com/api'; export function request(url, method = 'GET', data = {}) { return new Promise((resolve, reject) => { uni.request({ url: BASE_URL + url, method, data, header: { 'token': uni.getStorageSync('token') || '' }, success: (res) => { if (res.data.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { // token失效，重新登录 uni.removeStorageSync('token'); uni.navigateTo({ url: '/pages/login/login' }); reject(res.data); } else { uni.showToast({ title: res.data.message, icon: 'none' }); reject(res.data); } }, fail: (err) => { uni.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); }

还有一点值得注意：小程序的request域名必须是HTTPS，并且在微信公众平台的后台配置合法域名。我在本地开发时可以勾选“不校验合法域名”，但上线前一定要把这个配置处理好，否则真机预览一打开接口全挂。这个几乎是每个小程序新手必踩的坑，我身边至少有三五个朋友卡在这里好几天。

3.2 首页内容聚合与轮播图实现

首页是文化传承系统的门面，我的设计方案分三个区块：顶部轮播图、推荐陶器列表、最新资讯。轮播图的数据在后台可以配置，比如放一些大师作品、重大活动或者新品发布的宣传图，点击后可以跳转到对应的详情页。

轮播图组件uniapp提供了现成的swiper，不需要额外引第三方库。关键代码并不复杂：

<template> <view class="banner-wrapper"> <swiper class="banner-swiper" :indicator-dots="true" :autoplay="true" :interval="4000" :duration="500" circular> <swiper-item v-for="item in bannerList" :key="item.id" @click="goDetail(item.url)"> <image class="banner-img" :src="item.image" mode="aspectFill" /> </swiper-item> </swiper> </view> </template>

需要注意的细节是mode="aspectFill"，这个属性会让图片以“填充”模式铺满容器，同时保持比例，避免图片被拉伸变形。如果不设置mode，默认的scaleToFill在宽高比不一致时就会出现明显的压缩变形，首页会显得非常业余。

轮播图接口返回的数据结构我已经在后端定义好了：id、image、url、sort。其中url字段存的是跳转路径，比如/pages/detail/detail?id=3，前端拿到后用uni.navigateTo跳转即可。如果你要跳转到tabBar页面，记得改用uni.switchTab，用navigateTo是跳不过去的，这个是小程序API的一个限制。

推荐陶器列表，我用的是一列两行的网格布局，每个卡片展示封面、名称、简介和浏览量。前端请求/api/pottery/recommend拿数据，接口在pottery控制器里做：

public function recommend() { $list = Db::name('pottery') ->where('status', 1) ->where('is_recommend', 1) ->order('view_count desc') ->limit(6) ->select(); return json(['code' => 200, 'message' => 'success', 'data' => $list]); }

排序上我用浏览量做降序排列，相当于做了一个“热门优先”的策略，这样不用额外的人工干预，好的内容自然会被看到，也符合用户对“推荐”的预期。

3.3 坭兴陶文化专题页的内容呈现

这个模块是整个系统里最“有文化”的部分，我规划了三个维度：历史渊源、制作工艺、传承人物。这三个维度基本可以覆盖用户对坭兴陶的认知需求——知道它从哪里来、怎么做的、谁在做。

历史渊源部分，我在后台录入了一些坭兴陶的历史资料，从唐代始创、清朝贡品到民国时期的产业化发展，每一篇都配上老照片或器物图片。这里需要注意版权问题，老照片尽量用自己拍摄或者明确标注了允许使用的资源，不要随便从网上扒图，容易惹麻烦。制作工艺部分，重点展示从选泥、炼泥、拉坯、雕刻到烧制的完整流程。每道工序配一段短视频或者GIF动图的效果最好，加载体验比大图片更好。传承人物部分，就是典型的“人”的内容，每位大师的简介、代表作品、荣誉经历，都可以做成一个卡片列表。

这个专题页我个人建议用“Tabs切换”的形式来呈现，避免页面过长导致滚动失去耐心。uniapp里实现Tabs有两种思路：一种是简单的点击切换视图，用v-if或v-show控制对应区块；另一种是借助scroll-view做可滚动的Tab导航。我这边用的是第一种，逻辑最简单。

<view class="tab-container"> <view class="tab-item" :class="{active: currentTab === 0}" @click="switchTab(0)">历史渊源</view> <view class="tab-item" :class="{active: currentTab === 1}" @click="switchTab(1)">制作工艺</view> <view class="tab-item" :class="{active: currentTab === 2}" @click="switchTab(2)">传承人物</view> </view> <view v-if="currentTab === 0" class="tab-content"> <!-- 历史内容 --> </view> <view v-if="currentTab === 1" class="tab-content"> <!-- 工艺内容 --> </view> <view v-if="currentTab === 2" class="tab-content"> <!-- 传承人内容 --> </view>

3.4 详情页与富文本内容的处理

详情页承载的是用户“深入了解”的需求，无论是陶器详情还是文章详情，页面结构我建议统一：顶部大图、标题、参数信息区、正文区、底部评论区。

陶器详情页的images字段是JSON字符串，前端需要解析成数组，同时处理数组里为空的情况。推荐写成计算属性：

computed: { detailImages() { if (this.detail.images) { return JSON.parse(this.detail.images); } return []; } }

正文区如果是富文本，我用的是rich-text组件来渲染HTML。富文本是后台编辑器存的，里面带的图片可能会用绝对宽度，在手机端就会出现“图片比屏幕还宽”的灾难现场。解决办法有两个：一个是后台编辑时让图片样式设为max-width: 100%，另一个是在前端解析时用正则给图片路径加最大宽度样式。考虑到内容编辑者不一定都懂技术，我在后端写了一个内容过滤器：

public function formatContent($content) { // 给富文本图片添加自适应样式 $pattern = '/<img[^>]+>/i'; $replacement = '<img src="..." style="max-width:100%;height:auto;">'; return preg_replace($pattern, $replacement, $content); }

这里只展示处理逻辑，实际还要对src做提取。否则样式改了，图片源却被写死了，等于白处理。

评论区的实现涉及用户表、评论表两张表的关联查询。前端提交评论后，后端要校验用户是否登录、内容是否为空、长度是否超限。为了避免XSS攻击，对评论内容里的HTML标签要做过滤，简单方案是用htmlspecialchars转义后入库。显示评论列表时，用left join查出用户的头像和昵称。

public function commentList() { $potteryId = $this->request->param('pottery_id'); $list = Db::name('comment') ->alias('c') ->join('user u', 'c.user_id = u.id') ->where('c.pottery_id', $potteryId) ->field('c.content, c.create_time, u.nickname, u.avatar') ->order('c.create_time desc') ->select(); return json(['code' => 200, 'message' => 'success', 'data' => $list]); }

3.5 收藏与浏览记录的小功能优化

收藏是用户回访的重要入口。我在陶器详情页加了一个收藏按钮，用户点击后调用收藏接口，后端在收藏表里插入或删除记录，并返回当前的收藏状态。这个功能看似简单，但处理并发点击的时候要注意：用户快速双击按钮，可能导致插入两条重复收藏。我的做法是在收藏表设置(user_id, pottery_id)唯一索引，插入时用ON DUPLICATE KEY UPDATE或先查再插，保证数据唯一性。

浏览记录我选择了存本地（uni.setStorageSync）而不是存后端。原因是浏览记录的读写频率很高，每打开一个详情页就往后端写一条，会给服务器造成不必要的压力。存本地的好处是速度快、不消耗服务器资源，坏处是换手机或清除缓存后历史记录会丢失。但从文化展示类项目的使用习惯来看，浏览记录本来就是轻量需求，本地方案完全够用。每组浏览记录存pottery_id、title、cover、time，最多保存20条，超出部分自动剔除最早的记录。这个功能不难，但对用户体验的提升是实打实的。

4. 部署上线与常见问题排查

4.1 微信小程序打包发布的关键步骤

uniapp项目开发完成后，进入发布阶段，需要在HBuilderX里操作。步骤看起来简单，但每一步都有细节要注意，我按顺序梳理一遍：

1. 配置manifest.json：微信小程序AppID一定要填对，不只是用于打包，还影响登录和请求接口。在微信公众平台注册小程序后，会在开发设置里看到AppID。如果你还没有注册小程序，只是本地测试，可以勾选“测试号”选项，使用微信提供的测试AppID。

2. 配置合法域名：在微信公众平台“开发管理-开发设置-服务器域名”里，把后端接口域名添加进request合法域名，必须是HTTPS。如果还没有域名证书，可以用某些云厂商的免费证书先顶着，这个阶段先解决能访问的问题。

3. 发行菜单打包：在HBuilderX里点击“发行-小程序-微信”，会自动编译并打开微信开发者工具。这里有一个很常见的报错：app.json: ["tabBar" ...]。基本都是pages.json里的tabBar配置有问题，比如图标路径不存在、pagePath没在pages数组里注册。遇到这个报错先回检查pages.json，别急着去改代码。

4. 微信开发者工具预览和上传：在微信开发者工具里，点击“预览”生成二维码，手机扫码可以真机预览；点击“上传”会把代码传到微信后台，然后在后台提交审核。审核一般需要一两天，节假日可能更久，所以上线前一定预留时间。

5. 版本管理：第一次发布建议上传一个明显标记的版本号，比如1.0.0，方便后续版本比对和在后台回退。小程序后台的“版本管理”可以看到历史版本，万一新版本出了线上问题，可以快速回退到旧版本。

4.2 PHP后端上线的环境准备

PHP后端上线，我用的是宝塔面板加Nginx的组合，LNMP环境在宝塔上点几下就能配好。相比Apache，Nginx处理PHP并发请求的性能更好，配置也直观。在Nginx的配置里，要注意几个点：

第一，server_name要填域名，root指向项目的public目录。ThinkPHP的入口文件在public/index.php，如果把root指向项目根目录，访问时还得带上public，URL很丑，而且容易暴露目录结构。

server { listen 80; server_name yourdomain.com; root /home/wwwroot/ceramics/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s=$1 last; } } location ~ \.php(.*)$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }

第二，跨域问题。小程序端请求可以不处理跨域，因为小程序不是浏览器环境，不存在同源限制。但如果后续你嵌入H5，或者用浏览器调试接口，就要在后端设置跨域响应头。最简单的办法是在入口文件里加一个中间件，允许所有来源的跨域请求：

header('Access-Control-Allow-Origin: *'); header('Access-Control-Allow-Headers: token, Content-Type'); header('Access-Control-Allow-Methods: GET, POST, OPTIONS');

开发阶段用*没人管你，上线生产环境建议收紧，只允许自己的域名，防止别人拿走你的接口做数据抓取。

第三，HTTPS证书申请。小程序上线强制要求HTTPS，HTTP请求在小程序里是发不出去的。证书可以在腾讯云或者阿里云申请免费的单域名证书，有效期一年，到期后记得续期。宝塔面板里有一个“SSL证书”功能，把申请好的证书私钥和证书内容粘贴进去，再开启“强制HTTPS”访问，整个配置过程十分钟就能完成。

4.3 常见问题速查表

我整理了这几个项目里最容易出现的问题和排查方案，都是自己做项目时反复踩过的坑：

4.4 实测下来的性能优化建议

这个项目虽然体量不大，但上线后我还是做了两处性能优化，效果比较明显。

第一处是图片懒加载。首页和列表页的图片比较多，如果不处理，页面加载时会一次性并发请求所有图片，卡顿感很强。uniapp的image组件原生支持lazy-load属性，直接加上就行：

<image class="pottery-item-img" :src="item.cover" mode="aspectFill" lazy-load />

第二处是接口数据缓存。对于首页轮播图和推荐陶器这样短期不变化的内容，我在后端接口设置了浏览器的HTTP缓存头。虽然小程序端不一定是浏览器，但对HTTP缓存的处理是一致的。用户在5分钟内重复打开首页，内容直接从缓存读，几乎感觉不到加载延迟。

public function banner() { $list = Db::name('banner')->order('sort asc')->select(); // 设置缓存1小时 cache('banner_list', $list, 3600); return json(['code' => 200, 'message' => 'success', 'data' => $list]); }

这种简单的键值缓存虽然不高级，但在数据量几千条级别的场景里，已经能带来明显的速度提升，而且不会引入Redis这样的额外依赖。

我这个项目到最后，前端页面一共10个左右，后端接口30多个，覆盖登录、内容展示、收藏、评论这些核心功能。整个迭代过程里最有价值的一步，其实是提前把数据结构设计清楚，后面填充功能时就顺利很多。坭兴陶这个题材本身是很好的内容池，如果后续想扩展，还可以加线上预约参观、手工体验课程报名、大师直播链接之类的功能，接口架构和表结构都预留了扩展空间。

最后再分享一个小技巧：非遗文化类的项目，视觉风格最好稳重一点，颜色上可以从器物本身提取——坭兴陶的“窑变”色彩就是很好的设计灵感，深褐、赭石、暗红这些色系天然带有文化沉淀感。我自己前端切图的时候，特意让设计师做了一套偏暖褐色的主题色，出来的效果比普通的蓝色绿色主题要协调得多，也更契合文化传承这个定位。