```html

py网站

用Python建站？很多人第一反应是Flask或者Django，然后皱眉头——配置环境、网站写路由、网站调模板，网站一套下来半天没了。网站我上周帮朋友搭了个小型展示站，网站从零到上线只用了不到两小时，网站用的网站不是那些“正经”框架，而是网站http.server加几行jinja2。对，网站就是网站那个内置的、被无数教程嘲讽为“玩具”的网站模块。结果呢？网站跑得挺稳，朋友还挺满意。网站

这事让我重新琢磨“py网站”到底意味着什么。Python的生态里，做网站有太多条路。Django是大而全，Flask是轻而活，FastAPI是快而现代，但如果你只是要个静态页、一个内部工具、甚至临时API，真没必要上重武器。我见过有人为了展示五页文档，硬生生装了个Django，结果服务器内存吃紧，重启三次。杀鸡用牛刀，牛还嫌你烦。

“能跑就行”在个人项目里不是贬义，是效率。

拿http.server来说，继承BaseHTTPRequestHandler，覆写do_GET，返回HTML字符串。就这。你要是想动态点，用string.Template做个变量替换，或者塞个sqlite3读数据。我试过用这种方式给一个小团队做内网看板，每天刷新一次数据，跑了半年没出过毛病。代码总共不到80行，同事都能看懂，改起来也快。反观隔壁组用Django写的类似功能，光settings.py就200行，新人接手得先看三天文档。

当然，我不是说框架没用。项目大了、要用户系统、要后台、要ORM，那还是乖乖上Django或Flask。但很多“py网站”的起点被高估了——你不需要一开始就搞那么复杂。我自己的博客换过三次技术栈，最后落在Flask加SQLite，因为写起来顺手。可如果你让我给一个只展示简历的静态站推荐方案，我绝对会说：python -m http.server，然后扔进文件夹完事。加个--directory参数，连cd都省了。

还有个挺有意思的玩法：用Flask只做API，前端直接扔Nginx或Caddy。这样Python只负责逻辑，静态资源交给专业选手。我去年做的一个小工具站就这么干的，Flask跑在5000端口，Caddy反代并处理静态文件。部署脚本三行，性能比纯Flask模板渲染好一截。你说这算“py网站”吗？算，但又不全是。Python在里面是胶水，是脑子，不是手脚。

另外，别忽略WSGI和ASGI的区别。你要是用FastAPI写异步接口，却拿gunicorn配sync worker跑，那性能直接打骨折。我见过有人抱怨FastAPI慢，一问部署方式，用flask run的生产模式——这就像开跑车挂一档，然后怪车不行。工具没错，用错了场景。

说到底，“py网站”这个词太宽了。它可以是一个Bottle写的微型API，可以是Django撑起的内容平台，也可以是我那个80行的内网看板。没有哪种方案更高贵，只有合不合适。我现在的习惯是：先问需求，再选工具。如果需求是“明天上线，就五个页面”，那我连Flask都不装，直接http.server加jinja2，十分钟搞定。如果需求是“半年后要加支付和权限”，那老老实实Django起步，别折腾。

最后说个真事。上个月有个读者问我，他用Flask写了个博客，访问量一上来就502。我让他把debug=True关了，再用waitress跑，问题没了。他之前一直以为是代码性能问题，其实是开发服务器扛不住并发。你看，很多“py网站”的坑不在框架本身，而在部署那一步。Python做网站，写起来快，但跑起来稳不稳，得看你怎么配。

所以下次有人跟你说“用Python做个网站”，别急着打开pip install django。先想想，你到底要什么。有时候，最简单的那个模块，反而最顺手。