去年2月到4月，我以非技术专业学生的身份，接手了一个农业品牌官网的技术搭建。项目不大，但几乎把非科班能踩的坑都踩了一遍。这篇文章不写情怀，只写遇到的问题、排查过程和最终方案，希望能帮到同样在非技术背景下做网站的人。

一、WordPress 上传限制卡在 2M，只改 php.ini 没用

现象：WordPress 后台媒体上传最大限制一直是 2M，上传主题或大图直接报错。

排查过程：

  • 先找主 php.ini，修改 upload_max_filesize 和 post_max_size。
  • 改完重启容器，发现限制没变。
  • 用 phpinfo() 查看，发现主 php.ini 并不是最后生效的那个。PHP 会先加载主配置文件，再加载 conf.d 目录下的 *.ini，后加载的会覆盖先加载的。当时真正生效的是宿主机挂载的 conf.d/uploads.ini。
  • 另外 Nginx 还有一层 client_max_body_size 限制，默认只有 1M。

解决方案：

  1. 在宿主机对应站点的 uploads.ini 中设置 upload_max_filesize = 512M、post_max_size = 512M。
  2. 在 Nginx 站点配置中增加 client_max_body_size 512M;。
  3. 重启 WordPress 容器和 openresty 容器。

踩坑总结：PHP 配置可能被多个文件覆盖。用 phpinfo() 同时看 Loaded Configuration File 和 Additional .ini files parsed，才能定位真正生效的配置；Nginx 和 PHP 是两道门，只改一道没用。

二、AI 助手嵌入网站：Coze 的会话隔离问题

现象：用 Coze Web SDK 嵌入 AI 助手后，不同浏览器、不同设备看到的聊天记录是同一份，用户之间无法隔离。

排查过程：

  • 查 Coze 文档，发现使用个人访问令牌（PAT）时，所有请求共享同一个身份。
  • 尝试配置 JWT 鉴权，需要生成 PEM 私钥、设置 kid、调用 OAuth 接口，流程复杂且对非科班不友好。
  • 测试过程中还遇到网络拦截、token 泄露风险等问题。

最终方案：

  • 放弃在 Coze 内做会话隔离，改为使用 IFrame 嵌入。
  • IFrame 不依赖前端 token，部署更简单；但会话隔离仍取决于平台侧配置。
  • 后来把 AI 后端换成阿里云百炼，重新配置人设和知识库，由平台侧控制会话。

踩坑总结：会话隔离不能只靠前端传参——PAT 之下所有请求都是同一个应用身份，前端传什么都一样；鉴权方式和平台侧配置才决定隔离能力。对非科班来说，IFrame 是成本最低、部署最稳的嵌入方式，但不要误以为它“天然隔离”。

三、数据库连接失败：Error establishing a database connection

现象：网站突然无法访问，提示数据库连接失败；访问后台时还跳到了 WordPress 安装页面。

排查过程：

  • 用 docker ps -a 查看容器，WordPress 和 MySQL 容器都在运行。
  • 进入 MySQL 容器，在对应数据库下执行 USE wp; SHOW TABLES;，数据表完整，数据没丢。
  • 查看 WordPress 容器的环境变量，发现 WORDPRESS_DB_HOST 写的是 mysql:3306，但实际 MySQL 容器名是 1Panel-mysql-P0zo。
  • 容器在同一 Docker 网络内，但主机名不对，导致解析失败。

解决方案：

  • 先确认 wp-config.php 是“读环境变量”还是“硬编码数据库信息”。读环境变量的版本，重建容器并传入正确的 WORDPRESS_DB_HOST=1Panel-mysql-P0zo:3306 即可；硬编码版本要直接改文件。
  • 挂载原有的网站目录，保证文件不丢。
  • 重启后网站恢复。

踩坑总结：Docker 容器之间通过容器名通信，容器名不是固定的 mysql；数据库连不上时，先确认容器名和网络，再查账号密码，同时确认 wp-config.php 的读取方式。另外，“数据库连接失败”和“跳出安装页面”是两类原因——前者是连不上，后者通常是 wp-config.php 里的配置丢失或数据表找不到，排查时要分开看。

四、快照回退后，网站内容“回到过去”

现象：服务器出问题后回退到更早的快照，网站能打开，但文章、商品、页面都回到了旧版本。

排查过程：

  • 快照是系统级备份，回退的是整个服务器状态，包括数据库和文件。
  • 快照时间点之后新增的文章、商品、页面修改全部丢失。
  • 本地虽然有网站文件备份，但数据库备份有 .tar.gz 压缩包和解压后的 .sql 文件两种形态，恢复时容易搞混。

解决方案：

  • 优先使用应用级备份（网站文件 + 数据库）恢复，而不是系统快照。
  • 如果只有快照，回退后手动补录核心文章和商品。
  • 数据库备份如果是 .tar.gz，先解压出 .sql 再导入，不能拿压缩包直接导入。
  • 后续养成习惯：每次大改前，单独导出数据库 .sql 文件，并备份网站目录。

踩坑总结：系统快照不等于应用备份；数据库和文件要分开备份，恢复时先解压再导入，才能精准还原。

五、3D 手办模型导出 STL 尺寸过小

现象：在 Blender 里调整好的手办模型，导出 STL 后尺寸过小（不到 1cm），无法满足 3D 打印要求。

排查过程：

  • 检查模型在 Blender 中的尺寸，发现单位设置和缩放比例不对。
  • 导出时没有勾选“应用修改器”和“仅选中对象”。
  • 模型缩放后没有执行 Ctrl+A 应用缩放，导致导出数据与视口里看到的不一致。

解决方案：

  • 统一单位制为毫米。
  • 缩放后执行 Ctrl+A → 应用缩放。
  • 导出 STL 时勾选“应用修改器”和“仅选中对象”。
  • 用切片软件（如 Cura、Luban）或把 STL 重新导入 Blender 验证尺寸。

踩坑总结：3D 打印对尺寸和单位极其敏感；Blender 的缩放没有应用时，导出尺寸很可能和你在视口里看到的不一样。遇到“尺寸不对”，先查单位、缩放和导出选项，不要先怀疑文件损坏。

六、一点非技术层面的体会

技术问题有标准答案，但排查过程没有。 我遇到的大部分问题，网上都有零散的答案，但组合起来能跑通的很少。更多时候是靠 phpinfo()、docker logs、SHOW TABLES 这些最基础的工具，一步一步缩小范围。

另外，备份比想象中重要。项目后期我因为数据库回退丢过内容，后来养成习惯：改代码前备份文件，改数据前导出 SQL。

最后，非科班做技术，最大的优势不是“懂原理”，而是愿意查、愿意试、愿意把报错信息一条一条看完。这一点，比会多少命令都管用。