公司网站建设整体架构

一个公司网站挂了，公司最先出问题的网站往往不是代码，是建设架构架构。

去年帮一家做工业零件的整体客户排查故障，他们官网每天UV不到两千，公司但每到下午三点必卡。网站查了三天，建设架构发现是整体产品数据库和官网CMS共用一个MySQL实例，后台编辑传张产品图，公司前台加载就转圈。网站这就是建设架构典型的架构没分层——省事省出毛病。

前端：别急着上框架

很多团队一上来就React、整体Vue全家桶。公司但公司官网的网站核心诉求是"快速打开、能被搜到"。建设架构我见过一个做阀门的客户，首页用Next.js做了SSR，但图片没做懒加载，首屏请求了四十多张高清产品图，LCP飙到6秒。后来砍掉轮播图、改用WebP、加了个CDN，直接降到1.8秒。

静态页面能解决的问题，别用JS渲染。公司介绍、联系方式、新闻列表，这些用服务端模板（比如Go的html/template或PHP）输出HTML就够了。只有产品筛选、在线询价这类交互，才值得上前端框架。我的习惯是：首屏内容必须服务端直出，交互部分用Alpine.js或htmx这类轻量方案，整体JS体积控制在150KB以内。

后端：拆开但别拆碎

一个典型公司站的后端需求：内容管理、产品数据、表单提交、搜索。有人上来就微服务，四个功能拆四个容器，结果运维成本比开发还高。小团队用单体+模块化更实际。比如用Django或Laravel，把CMS、API、表单处理分在不同app目录，共用一个数据库连接池，部署就一个进程。等日活过万再考虑拆。

数据库选型也类似。MySQL够用就别上MongoDB。产品表、新闻表、询价记录表，三张表加索引能撑很久。我经手的一个机械配件站，产品SKU八千多，用MySQL的全文索引做搜索，响应稳定在80ms内。后来他们非要换Elasticsearch，集群维护费每月多花两千，搜索质量没明显提升。

部署：CDN不是万能药

很多人以为套个Cloudflare就高枕无忧。但CDN只缓存静态资源，动态请求（比如询价表单提交）还是回源。如果源站是单台2核4G的云服务器，并发一高照样崩。我的做法是：静态资源全走CDN，动态接口用Nginx做反向代理+限流，数据库加Redis缓存热点查询。去年双十一，一个客户官网瞬时并发冲到3000，因为产品列表页走了Redis缓存，源站CPU只到40%。

还有个细节：公司网站经常被爬。产品价格、联系方式被竞品抓走是常事。在Nginx层加个频率限制，同一IP每分钟超过60次请求就返回429。再配合前端表单加个简单的算术验证，能挡掉九成脚本小子。

安全：别等出事再补

公司站最容易被盯上的是后台登录和文件上传。我见过一个案例，客户用WordPress，管理员密码设成"admin123"，插件三个月没更新，结果被挂马跳转到博彩站。基础措施：后台强制两步验证，上传目录禁止执行PHP，数据库账号只给CRUD权限不给DROP。每周自动备份到对象存储，保留最近30天。这些花不了多少时间，但能救命。

架构没有标准答案。一个二十人的贸易公司，和一家两千人的制造企业，官网的技术选型天差地别。关键是先想清楚：谁用、用来干什么、能容忍多慢、出故障了谁修。想明白这四个问题，架构自然就出来了。