真实落地案例熵衍科技 AI 解决方案官网

为某企业服务方向客户构建的 AI 解决方案展示官网，采用 React 18 + TypeScript + Vite 技术栈，支持响应式设计、安全头配置与 Docker + Nginx 容器化部署。

项目背景

客户需要一个能够系统化展示其 AI 技术解决方案的企业官网，核心诉求包括：响应式多端适配、内容模块灵活可配置、生产环境安全合规、部署流程标准化。该客户此前使用 WordPress 搭建的旧官网因插件漏洞被挂过黑链，因此对安全策略和部署可控性要求极高。

功能范围

• 企业官网：完整的企业信息架构与品牌展示
• 响应式设计：适配桌面、平板、手机三端
• 内容展示：技术方案、产品、案例的结构化呈现
• 安全头配置：CSP、HSTS 等生产环境安全策略
• Docker 部署：Nginx 反向代理 + 容器化一键部署

技术实现

工程决策与取舍

为什么不选 Next.js SSG 而用纯 CSR？

这个决策在项目初期争论了一周。客户官网内容以技术方案展示为主，涉及大量动态图表和交互组件（产品对比、架构图缩放等）。Next.js SSG 方案虽然 SEO 更友好，但客户的核心流量来自销售团队线下推送 + 微信渠道，而非搜索引擎自然流量。最终选择 CSR + Vite：开发体验更轻，部署只需一个 Nginx 静态容器，省去了 Node.js 服务端运维成本。代价是首屏 SEO 偏弱，后续如有需要可通过预渲染插件补齐。

安全策略的平衡

CSP 策略最初配置过于激进——禁用了所有 inline script，导致 Arco Design 的部分组件（Modal、Notification）内部使用的动态脚本注入被拦截，页面在 Safari 上出现白屏。最终调整为允许 'unsafe-inline' 但配合 nonce 机制，同时开启 HSTS（max-age=63072000，includeSubDomains）和 X-Content-Type-Options: nosniff。上线前用 Mozilla Observatory 跑分：从最初的 D 级提升至 A+。

一个踩坑记录：Docker 多阶段构建的包版本漂移

CI 流水线中 Docker 构建阶段和最终运行阶段使用的 Node 基础镜像版本不一致（build 用 node:18-alpine，run 用 nginx:alpine）。某次依赖升级后，构建阶段拉到的 sharp 原生模块在 Alpine 的 musl libc 下编译通过但运行时因缺少 libvips 动态链接库导致图片处理 500。解决方案：在 Dockerfile 中显式声明 apk add --no-cache vips-dev 并固定 sharp 版本号。这个坑花了半天排查，但教训值回票价——永远不要在 CI 中放任包管理器的隐式依赖解析。

交付内容

• 项目源文件与可运行工程结构
• 围绕业务功能整理的产品与技术文档
• 适配 Web 端的前台展示界面
• 案例展示所需的行业、技术栈、功能范围和 SEO 信息
• Docker Compose 一键部署脚本 + Nginx 配置模板（含安全头策略）

项目价值

该案例展示了企业官网类项目从需求梳理、技术选型到容器化部署的完整链路。对同类项目而言，已确认的功能范围和技术选型可作为需求评估、报价拆分和交付排期的参考基准。特别是在安全合规方面——CSP/HSTS 配置、Docker 镜像瘦身、CI 流水线中的依赖锁定——这些看似细节的工程决策，往往决定了项目上线后是持续维护还是反复救火。