得，今天就来唠唠网站设计和架构这事儿。每次有人，特别是刚入行的小年轻或者干脆是外行朋友问我：“欸，你们做网站的，那玩意儿到底咋回事？” 我就觉得，这事儿还真不是一两句话能说明白的。不是装深沉，是这东西确实得分开揉碎说才行。

我刚开始琢磨怎么跟人解释清楚的时候，也是抓耳挠腮。后来我发现，得从自己实际干活的流程来讲，人家才更容易听懂。

我是怎么开始理解和介绍“设计”这块的

你想，一个网站，别人第一眼看到的是肯定是界面嘛好不好看，用着顺不顺手。这就是“设计”这部分要干的事。但这不光是画个漂亮的图那么简单。

• 先搞清楚给谁用： 我一开始做东西，也容易光想着自己觉得酷，后来发现不行。得先琢磨明白，这网站是给什么人用？是给大爷大妈买菜的，还是给年轻人看视频的？用户不一样，设计思路就得完全不同。
• 琢磨用户怎么用： 这步特别关键。我会想象用户点进来，第一眼会看哪里，鼠标会往哪里移动，想找个东西，他会怎么找。按钮放哪儿最方便？字用多大看着不累？颜色搭不搭配？这些都得细细抠。这不叫啥专业术语，就叫“用户体验”，说白就是让用的人觉得舒服、方便。
• 画草图和原型： 想得差不多，就不能停留在脑子里。我习惯先拿纸笔随便画画，或者用些简单的工具搭个大概的架子，我们叫“原型”。这样能快速看到效果，哪里不顺眼，哪里流程不对，改起来也快，不至于一开始就陷到细节里。
• 视觉落地： 原型定，才开始搞“视觉设计”，就是把网站弄得漂漂亮亮的。选颜色、配图片、定字体啥的。但这步也得想着前面的用户和功能，不能为好看牺牲易用性。

设计这块，说到底，就是搞定网站的“面子”和“用户感受”。

接着是“架构”这块，网站的“里子”

光有个好看的壳子不行，用户点个按钮，提交个信息，这些动作背后得有东西支撑着运行才行。这就是“架构”要解决的问题。这块水就比较深，但往简单说，就是搭好网站运行的骨架子。

我自己的经验是，这块得考虑下面几个方面：

• 选什么“语言”干活： 就像盖房子选砖头水泥一样，网站也得选工具。是用PHP、Java、Python还是别的什么语言来写后台逻辑？这个选择影响很大，关系到开发效率、运行性能、以后维护麻不麻烦等等。我刚开始也是哪个火用哪个，后来发现得看具体项目需求，没有哪个是万能的。
• 数据存哪儿： 用户的注册信息、发布的内容、订单记录…这些数据得找个地方存起来？这就是数据库的事。用MySQL？PostgreSQL？还是其他的？数据量大怎么办？查询慢怎么办？这些都得提前规划我吃过亏，一开始数据库设计不后面数据量一上来，整个网站卡得要死，改起来那叫一个痛苦。
• 服务器怎么安排： 网站的代码和数据总得放在某个地方让大家能访问到？这就是服务器。一开始可能就一台服务器全包。但访问的人多，一台机器肯定扛不住。这时候就得考虑多搞几台机器，怎么让它们分工合作，比如有的专门处理用户请求，有的专门放数据库，有的专门存图片视频这些大文件。还得考虑万一有台机器挂，网站还能不能正常用（这就是所谓的“高可用”）。以前弄个小网站可能觉得无所谓，现在稍微正规点的项目都得考虑这些。
• 它们之间怎么连接和沟通： 前端界面（设计那块做的）、后台逻辑（选的语言写的）、数据库、服务器…这些部分不是孤立的，得让它们能互相通信，协同工作。比如用户在前台点“购买”，后台得知道，然后去数据库里改库存、生成订单，再告诉前台“购买成功”。这个流程怎么设计才高效、稳定，也是架构要考虑的核心问题。

架构这块，就是保证网站能稳稳当当跑起来，能处理用户的各种操作，还能应对访问量变化，并且以后方便扩展和维护。

把它们捏合起来看

你看，设计和架构，是相辅相成的。光有好的设计，后台架构跟不上，那网站就是个花架子，看着好看不能用。反过来，架构再牛逼，设计得乱七八糟，用户根本不想用，那也白搭。

所以我跟别人介绍的时候，总是强调这两块都得关注。我会先从用户能直接感受到的“设计”说起，说说怎么让网站好用好看，然后再深入到背后支撑这一切的“架构”，说说怎么保证网站能稳定运行、处理数据。这样一步步讲下来，从外到内，对方就比较容易理解一个网站是怎么从无到有被构建起来，并且能够运转的。

这里面每一小点深究下去都有很多门道，但作为介绍，我觉得讲清楚这两个大的方面和它们之间的关系，就差不多能让人有个整体的概念。这都是我自己实践中总结出来的土办法，不一定多专业，但应该还算实在管用。