前言
之前学过用Django来写后端，整体来说还算好用，但是还是花了好几天，Django的用法以及配套的DRF。
写了一个简单的项目后，几乎是再也没拿起过这个框架。
其中一个原因是这个框架太重了，有点java里面springboot的那种感觉，就是写一个demo需要配置一大堆东西，就感觉心累。
于是乎去找几个新的，更先进的框架。
列表
fastapi
之前面试过一家公司，说他们后端用的fastapi。
其实稳妥来说用这个没啥问题，足够热门足够轻量。
但是我就是喜欢搞点新的东西，而fastapi出现得很早，算不上先进。
Litestar
litestar-org/litestar: Light, flexible and extensible ASGI framework | Built to scale
Litestar被称为进化版的fastapi
整体来说没遇上什么大问题。
就是这个litestar run，默认是运行当前目录的app.py，而使用uv init创建的项目，主程序入口是main.py,让人产生了一些困惑。
另外就是这个route_handlers让人感觉有些蠢，不够简洁。
也没有自动推断，写python还必须声明返回值，不写就不让运行，于是还是觉得蠢。
Robyn[不推荐]
纯纯冲击波，request.files对象是个类字典对象，然而里面的键名是文件名，而不是字段名，不是哥们谁家文件上传能约定死文件名的？
性能在python web框架中是一个伪需求，高性能固然很好，但是牺牲开发效率得不偿失，解析表单都要手写那纯恶心人了。
sparckles/Robyn: Robyn is a Super Fast Async Python Web Framework with a Rust runtime.
这个是最有槽点的，容我娓娓道来。
-
创建项目
shelluv init xxx uv add robyn
到这其实就出问题了，首先需要rust环境，于是在windows上，需要安装rustup工具链。
winget install --id Rustlang.Rustup
我没记错的话，rust构建还依赖于c++构建工具，因此在windows上需要安装微软的Build tools。
这些还好接受，之前尝试tauri的时候有被恶心过。
于是跟着官方文档，开始第一个demo应用。
from robyn import Robyn
app = Robyn(__file__)
@app.get("/")
async def h(request):
return "Hello, world!"
app.start(port=8080)
python -m robyn .\main.py
然后还是没跑起来，报错一大段，大致分析了一下，是python版本高了，不兼容。
前段时期，python升级到了3.14版本，具有`πthon`彩蛋。
毕竟是近期更新的，不兼容可以理解，降呗。
uv我也不是特别熟，降级还略麻烦。
# 先尝试
uv venv --python 3.13
# 然后测试版本
python --version
# > 3.14
# 反正没成功，后续在pyproject.toml中删除了指定python版本的字样
# 又删除了.venv目录，再次执行上面的命令，这才更换成功。
# 于是乎我又尝试运行
python -m robyn .\main.py
然而默认不是以开发模式运行的，这一点也挺难让人理解，而且文档里面指引也不是开发模式。
这一点就不如前端，人家至少知道要先开发才能部署，甚至有些脚手架默认自动打开浏览器
> 强调这一点的原因是，开发模式具有热重载（在此处是热重启），可以检测代码的更新然后自动重启服务，提升开发效率。
ts生态里面HMR秒了。
python -m robyn .\main.py --dev
而且前面没提这个robyn文档里面的运行命令参数也是执行不了。
shell> (other) PS D:\code\other> python .\main.py --dev > Dev mode is not supported in the python wrapper. Please use the Robyn CLI. e.g. python3 -m robyn app.py --dev
然后自然也是出问题了。这次没看懂什么意思，直接扔给AI了，于是乎人家说，watchdog（掌管热重启功能的模块）不适配当前python版本。也是非常woc。
最终换到的3.12版本，也是成功运行了。
别的没啥可说的，自带一个docs，还不错。
文档也是非常搞笑，推荐你使用最新版本。
starlette
fastapi框架，基于starlette，假如要用这玩意，干脆直接用fastapi得了。
Sanic[不推荐]
已经有八个月没有更新过，这对于一个框架来说简直匪夷所思。
--dev无法开启开发者模式，本地docs文档引用人家的cdn，结果地址不能用。
Django[不推荐]
Django是一个重型框架，需要学习框架本身以及DRF。
如果使用重型框架，我认为不如直接使用Java Springboot。
推荐
除了Robyn，其他的都可以用，看喜欢哪一个。
性能上LiteStar很好，生态上fastapi无敌，在开源社区经常能看到fastapi写的项目。
至于Sanic，性能也还不错，我对他的文档有莫名的好感。
python吐槽
前面都在说web框架，标题上的吐槽python呢？
我不知道我以前是为什么能忍受python的。
python的包管理工具，即使是uv，也完全不够好用，在我看来完全比不上pnpm之类。
python的第三方包里面有不少包并不是纯python的，假如接触过某些开源项目，想把他跑起来，多少有些费劲。
以llamafactory为例，你想把这玩意跑起来并不简单。
当时我为了追求先进的包管理工具，强行使用uv去跑这个项目，结果就是搞半天搞不出来。
于是乎后面换了conda，情况好了很多。（就是因为conda并不是纯python的包管理工具，而且conda有预编译包，省很多事）。
然而在windows上，搞这玩意依旧恶心，因为有某个依赖对windows支持不太好，甚至很多教程是在WSL里面去跑项目。
我自然是不服气，花了很多时间搞这玩意。
-
糟糕的跨平台，语言跨平台，我的包不跨平台，windows能跑的应用，我放到Linux上不能跑，需要换其他包。
这一点rust也是，rust要跨平台需要到目标平台上编译，因此就有了使用github actions来构建多平台包的用法。然而那个actions已经被标记为归档，不再更新，只是恰好还能使用。
与此相比，go语言跨平台真是爽，我在windows x86上成功编译出linux arm64的二进制可执行文件，并在安卓手机的Termux终端环境下执行
-
混乱的包管理。nodejs发展到现在，包管理器有不少，npm、yarn、pnpm、bun。
然而在python里面，包管理乃至项目管理工具有一大堆。
除了uv，目前还有几个新兴的管理工具，比如PDM。
-
历史遗留问题
比较反直觉的是，Python是一个非常古老的编程语言。
Python比Java出现得更早。（即使有很大一部分观点认为应当将python3划为新的语言，这就纯扯皮，那Java 21和Java 8差别也大了去了）
这方面细化有很多可说，比如第三方包对异步的支持、python新版本的破坏性更新。
有不少项目甚至指明了需要使用哪个python版本来运行。
解决python依赖冲突和解决Linux环境依赖冲突有的一拼。
还有就是类型标注，typescript发展得很早，而且vscode和typescript都是微软开发的，推广起来非常轻松，到现在js已经完全是ts的形状了。然而python的第三方包不管你这那的，有标注算你先进，没标注你也不能拿我怎么样（总之就是质量层次不齐）。
而且类型推断完全一坨，完全比不上ts（有个好爹就是不一样）。
沟槽的缩进
饺子醋这一块。
缩进在某些层面很好，它以最简洁的方式来提供信息（在很多语言中，缩进不具有意义，然而在python中具有，这使得python更加简洁）。
然而，缩进妨碍我粘贴代码了。
这自然不是我第一次发现它对粘贴代码的影响，我也不知道我怎么忍下来的。
复制一段代码然后粘贴到方法里面，按下格式化按键。
我一直崇尚简洁，于是乎在试用vscode insiders时，我使用了insider的配置（空的）。 于是在看到这玩意时，第一反应就是很烦（无论是需要点一下安装，还是意识到就算格式化也没有用）。
题外话
其他框架
我还尝试了其他框架，其中最垃圾的就是Kotlin的ktor框架，热重载都载不明白，gradle极其恶心。
C#生态（dotnet rest api）极其繁重，初始化个项目就能劝退。
练习 - 创建 Web API 项目 - Training | Microsoft Learn
php的webman具有相当高的性能，但是不支持windows，php的相关配置也是比较古老，没有开箱即用的体验。
对比下来，其实python也不那么差。python具有极高的简洁性，这一点只有js能与之相比。
quarkus框架具有相当高的性能，支持kotlin，不过这个支持也只是说说而已，文档里面示例全是Java，对我来说Java是一个非常不简洁的语言。（况且Maven和Gradle也是遭罪）
哦对了还有go语言，go语言在web中显得非常不简洁，因为经常会有出现错误的情况，而go语言捕获错误只能使用if，没有try catch，导致代码里面一大堆if err != nil 。而且那个包管理器也是，为了去中心化搞得依赖名称特别长。（go语言可以使用Air，检测代码变化自动构建，实现热重启）
rust是我纯菜不想学。（Axum具有数一数二的性能表现）
图省事我就直接用ts写后端了。
然而ts写腻了，没有新鲜感。
于是乎又捡起python，诶真香。
项目管理工具
在node环境中，npm等包管理器同时承载着项目管理工具的作用。
比如在package.json中，可以自定义scripts，方便一键启动项目。
然而在python中火得一塌糊涂的包管理器 -- uv并不支持自定义脚本。
可以使用PDM，一个现代化的python项目管理工具。
当然，在项目根目录安放自定义脚本也是一种方式，然而这种方式不具备正当性和标准性，没有人能够规范你的脚本的名称。
而且如果使用pwsh，就更不能这么做了。
当然，也可以什么都不做，直接把命令塞在README.md中。
由于你无法确认其他人使用什么包管理工具，这是一种最轻量化的方式。
总结
文章的主要篇幅是一个踩坑记录，最终得出的是一个无用的结果。
无论最终结果是否有益，唯一确信的就是这些尝试拓宽了我的眼界，引起了我的思考，尽管这些东西难登大雅、微不足道。
[那些小众的编程语言 - 摸鱼派](https://fishpi.cn/article/1735655919063)
另外之前还探究过前端测试工具，比如Puppeteer、Playwright、Cypress这些，最终得出的结论是完全没有必要，编写成本还是高，并且引入了不必要的复杂性。除非是专业的测试人员，否则没有必要。
