雅雅蒂艺术建站编辑组发布时间：2026/10/14 2:53:39 来源：雅蒂艺术建站分类：艺术建站

在线制作网站页面避坑指南：被黑后我重构了3个核心环节

上周凌晨两点，我的手机疯狂震动。运维同事发来的截图显示，公司官网首页被挂上了一个赌博广告，源代码里赫然多了一段混淆过的 JavaScript。那种心脏骤停的感觉，只有经历过的人才懂。那一刻我才意识到，以前我们依赖的某些“在线制作网站页面”的便捷思维，正在变成安全隐患的温床。很多初学者甚至资深开发者，都掉进了“所见即所得”的陷阱，以为拖拽几下就能上线，却忽略了底层的安全加固和性能优化。

这次事故后，我花了整整一周时间复盘，并结合最近一个从 0 到 1 重构客户官网的案例，梳理了一套最佳实践。这套流程不仅解决了被黑挂马的根源问题，还让新站点的加载速度提升了 40%。今天我就把这个真实案例拆解给你看，看看我们是如何在“在线制作网站页面”的表象下，建立起真正健壮的技术底座。

项目背景与需求：为什么传统建站方式行不通了

这次接手的客户是一家中型外贸 B2B 企业，之前的官网是用市面上常见的可视化编辑器在线制作的。他们的痛点非常典型：

安全性极差：上次被黑后，SEO 排名跌出了前 20 页，Google 甚至给出了安全警告。
性能瓶颈：可视化编辑器生成的代码冗余度极高，一个首页加载下来，HTTP 请求超过 60 次，LCP（最大内容绘制）时间高达 4.5 秒。对于外贸站来说，这简直是自杀行为。
维护困难：运营人员不懂代码，每次改个文案都要找开发，而且经常改崩页面布局。

我们的需求很明确：放弃那种纯拖拽式的“在线制作网站页面”工具，转向低代码与代码结合的方案。既要保留运营人员可自助更新内容的便利性（类似在线制作的体验），又要具备传统开发的安全性和高性能。

这就引出了核心技术选型的问题：我们到底该怎么选？

技术选型：在“便捷”与“控制”之间找平衡

在对比了 Next.js、Nuxt.js 和传统的 WordPress 方案后，我们最终选择了 Nuxt.js 3 + Vue 3 作为前端框架，后端接口使用 Node.js (NestJS)，数据库采用 PostgreSQL。

为什么这么选？这里有个关键的对比逻辑：

维度	传统可视化建站 (如 Wix/Elementor)	CMS 系统 (如 WordPress)	Nuxt.js 3 (本方案)
页面生成方式	纯前端拖拽，服务端仅存配置	数据库存储内容，模板渲染	SSG (静态生成) + ISR (增量再生成)
SEO 友好度	一般，JS 依赖重	较好，但插件多易冲突	极佳，首屏直出 HTML
安全性	黑盒，漏洞难排查	插件漏洞多，需频繁更新	代码可控，依赖项少
维护成本	低（但功能受限）	中（需懂 PHP/DB）	高（需懂前端工程化）

对于被黑过一次的网站，可控性是第一优先级。Nuxt.js 的 SSG 模式意味着大部分页面是静态文件，直接部署在 CDN 上，根本没有服务器交互入口，黑客想挂马都找不到地方注入。只有动态数据（如询盘表单、博客更新）才通过 API 交互，攻击面大幅缩小。

这里有一个很多初学者容易忽视的点：不要把“在线制作”等同于“无代码”。真正的最佳实践是，开发搭建好组件库和布局容器，运营通过后台结构化录入内容，前端自动拼装成页面。这比直接拖拽控件要安全得多，因为组件是经过安全审计的。

核心实现：代码层面的安全与性能加固

光选对技术栈不够，细节决定成败。在这次重构中，我们重点加强了三个环节的代码实现。

1. 严格的输入校验与 XSS 防护

之前被挂马，很大程度上是因为后台富文本编辑器没有过滤恶意脚本。这次我们引入了 DOMPurify 对富文本内容进行清洗。

在后端 NestJS 服务中，我们定义了一个全局守卫：

import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { plainToInstance } from 'class-transformer';
import { IsString, IsNotEmpty, Matches } from 'class-validator';
import { validate } from 'class-validator';
import * as DOMPurify from 'dompurify';
import { JSDOM } from 'jsdom';@Injectable()
export class SecurityGuard implements CanActivate {canActivate(context: ExecutionContext): boolean {const request = context.switchToHttp().getRequest();// 模拟后端接收到的富文本内容const rawContent = request.body.content || '';// 使用 DOMPurify 进行白名单过滤，移除所有 script 标签和 onerror 等事件const dom = new JSDOM();const cleanContent = DOMPurify.sanitize(rawContent, {ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'ul', 'ol', 'li', 'a'],ALLOWED_ATTR: ['href', 'target'],});// 校验链接是否合法，防止 javascript: 伪协议if (cleanContent.includes('javascript:')) {throw new Error('Invalid content detected');}request.body.content = cleanContent;return true;}
}

这段代码看似简单，但它阻断了我上次遇到的大部分攻击向量。很多“在线制作网站页面”的工具默认信任用户输入，而我们必须默认一切输入都是恶意的。

2. 前端组件的安全渲染

在 Vue 组件中，严禁直接使用 v-html 渲染未经过滤的数据。如果必须使用，必须配合上述的后端过滤，或者在前端再次进行净化。

我们封装了一个安全的富文本组件：

<template><div class="rich-text" v-html="sanitizedContent"></div>
</template><script setup lang="ts">
import { ref, watch } from 'vue';
import DOMPurify from 'dompurify';const props = defineProps<{content: string;
}>();const sanitizedContent = ref('');watch(() => props.content, (newVal) => {if (newVal) {// 前端二次清洗，防止后端漏网之鱼sanitizedContent.value = DOMPurify.sanitize(newVal, {ALLOWED_TAGS: ['p', 'br', 'strong', 'em', 'ul', 'ol', 'li', 'a'],ALLOWED_ATTR: ['href', 'target'],});} else {sanitizedContent.value = '';}
}, { immediate: true });
</script>

这种双层防御机制，确保了即使后端被攻破，前端也不会执行恶意脚本。

3. 构建时的代码分割与压缩

为了提升性能，我们在 nuxt.config.ts 中配置了精细的代码分割策略：

export default defineNuxtConfig({build: {transpile: ['vue', 'vue-router'],},vite: {build: {rollupOptions: {output: {manualChunks: {'vendor-vue': ['vue', 'vue-router'],'vendor-utils': ['axios', 'dayjs'],},},},},},nitro: {preset: 'vercel', // 假设部署在 Vercel，也可改为阿里云 Edge Functionminify: true,},
});

通过手动分割 chunks，我们将核心框架代码和业务代码分离，利用浏览器缓存特性，让回访用户的加载速度接近于零。

上线与优化：从阿里云官方文档看部署细节

代码写得好，部署也得跟上。这次我们选择将静态资源托管在 阿里云 CDN，动态 API 部署在阿里云函数计算（FC）上。

这里有一个关键细节，很多新手会忽略：HTTPS 强制跳转与 HSTS 配置。

根据阿里云官方文档关于“配置 HTTPS 证书”的建议，仅仅配置 SSL 证书是不够的，必须开启 HSTS（HTTP Strict Transport Security）响应头。这能防止中间人攻击通过降级协议来窃取数据。

在 Nuxt.js 的 server/middleware/security.ts 中，我们添加了以下中间件：

export default defineNitroEventHandler((event) => {// 设置 HSTS 头setHeader(event, 'Strict-Transport-Security', 'max-age=63072000; includeSubDomains; preload');// 设置内容安全策略 CSP，进一步限制资源加载来源setHeader(event, 'Content-Security-Policy', "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;");// 防止 MIME 类型嗅探setHeader(event, 'X-Content-Type-Options', 'nosniff');// 防止点击劫持setHeader(event, 'X-Frame-Options', 'DENY');
});

CSP（内容安全策略）是这次防黑的最后一道防线。它告诉浏览器：“只允许加载我自己域名的脚本，其他的一律拒绝。” 即使黑客成功注入了脚本，浏览器也会直接拦截执行。

上线后，我们使用 Lighthouse 进行了全面检测：