建站时埋下、后期很难修复的隐患

核心特点：不是改改文字样式就能搞定，往往要动底层架构、数据库、权限逻辑，甚至部分需要重做站点；很多问题平时看不出，上线久了、流量上来才爆发。

一、底层架构与程序选型类（难改）

随便选用小众 / 停止维护的源码、CMS建站图省事用不知名源码、多年不再更新的旧版 CMS。后期：漏洞没人修补、没有插件、找不到开发者，一旦被黑客入侵，没法打补丁。想迁移内容，数据库结构不通用，导出导入非常麻烦，很多字段错乱。

对比：主流 CMS（WordPress、Dede、Typecho、帝国等）至少社区有资料，但旧版本依然坑。
前后端代码耦合严重、没有分层页面代码、业务逻辑、SQL 查询混写在同一个文件里。改一个功能，很容易连带崩其他页面；想做改版、加新模块，牵一发而动全身。很多外包小站容易踩这个坑。
数据库设计缺陷
- 缺少索引：数据量变大后查询极慢，后台卡、页面加载超时；后期加索引要锁表，量大时会直接停机。
- 字段设计不合理、冗余字段、缺少关联约束：数据越来越多出现脏数据（重复、空值、无效记录）。
- 没有分库分表规划：适合小站，一旦数据几十万 +，重构数据库成本极高，还要做数据迁移校验。
- 没有备份机制、没有定时备份脚本：一旦删库中毒，数据直接丢失。
服务器 / 环境选型错误一开始贪图便宜用低配虚拟主机，或者 Windows 环境跑 PHP 站点。后期流量上涨，迁移到云服务器要改路径、权限、伪静态；有些程序环境依赖特殊扩展，迁移后大量页面 404。还有：域名和站点绑定混乱、一开始用 IP 建站，后期换域名大量链接失效。

二、安全类隐患（出事代价大，修复繁琐）

权限配置过大web 目录给了 777 全开权限、数据库账号直接 root 权限。黑客拿到一句话木马就能拿下整台服务器。后期要逐目录、逐个文件重设权限，文件数量多的时候工作量巨大，一不小心弄成 500 错误。
没有做输入过滤，SQL 注入、XSS 漏洞原生存在代码直接接收用户参数拼 SQL，前端不转义输出。这种属于底层代码漏洞，不是装个安全插件就能根治。简单防护只能临时挡攻击，彻底修复需要逐页改写代码。
后台地址、弱密码、文件上传漏洞上传接口没有校验文件类型，允许上传 php/asp 脚本文件。很多站点被挂黑链、挖矿木马就是这个原因。修复要重写上传逻辑，还要全网扫描清理已经上传的恶意文件。
没有 HTTPS 规划、证书配置错误建站全程 http，后期想切 https 会出现大量混合内容报错（图片、js、css 还是 http）。如果大量硬编码写死 http 地址，需要批量改代码 + 数据库，还会影响 SEO。

补充：SSL 证书只是一部分，全站资源硬编码 http 是大坑。

三、SEO 与 URL 结构类（改了伤流量，几乎不敢动）

URL 结构设计不合理，后期无法修改比如 URL 带 ID、中文、特殊符号，或者层级太深；或者静态 / 伪静态规则写得很差。

难点：上线收录后，一旦修改 URL，旧链接全部失效。虽然可以做 301，但大量 301 会损失权重，工作量巨大。很多网站宁愿一直用烂 URL 也不敢重构。
硬编码写死域名、站内链接代码、模板、数据库里大量写死 shturl.cc/YAHg，不是相对路径。后期换域名、迁移服务器，需要批量替换，极易漏改，出现大量死链。
缺少标准化元信息、重复页面、无规范 canonical分页、筛选页面生成大量重复内容，没有 canonical 标签。等到被搜索引擎判定重复内容降权，再批量处理页面规则，工作量巨大。
图片资源无规范，图片地址硬写、没有图片压缩 / CDN 规划图片全部存在站点服务器，不做缩略图；图片链接写死域名。后期图片越来越多，服务器带宽扛不住；迁移图片需要迁移海量文件，还要改数据库里图片地址。

四、业务功能与扩展性隐患（越用越难加功能）

没有统一的接口，业务逻辑硬写死比如支付、短信、会员逻辑直接写在页面里。后期要更换支付服务商，几乎要重写整套业务代码，不能简单配置切换。
会员体系设计缺陷用户密码明文存储（高危！）；用户信息表缺少字段；权限模型简单，后期要加角色、分级权限，需要重构用户模块，还要迁移已有用户数据，风险高。明文密码一旦泄露，责任很大。
没有日志系统不记录访问日志、操作日志。遇到被攻击、用户反馈异常时，无法排查问题；后期补日志系统，需要改造底层代码。