vitality

一般有两种方式：
1. 上传前就转码/压缩图像，比如转码为 50% 质量的 AVIF 。
2. 使用 CDN 的图像处理，比如腾讯云的数据万象，比如 Cloudflare Images 或 Cloudflare Image Resizing 。这种方式存储的是原图，但可以在显示时、下载时，获取到转码/压缩过后的图像。

@panbofeng 反正我不支持

@x86 多一点 GFW 出入口带宽分流总是好的，就相当于多修一条公路，缓解拥堵。

@xyz3210 #22 不是这样的。
以前 GFW 只部署在北上广，所有公网流量都要到先到北上广，再分发出去/回来。
现在新增昆明（电信，将运营）、南宁（移动，暂无消息）、青岛（联通，将运营）、海口（三网，预计 2026-2027 年运营），这几个是和北上广同层级的国际互联网通信出入口局，也都会部署 GFW ，面对公众启用。
举个例子：以前成都-新加坡的路由可能是 成都-广州-香港-新加坡，现在就会多一种方案：成都-昆明-曼谷-新加坡。

我的看法是当然要保持更新。因为新的事物可以让开发者减少心智负担（情绪价值，开发更容易），可以让开发者开发出更出色的产品（提升产品质量），可以减少服务的资源消耗（减少成本）。
但如果太新的话，除非有必要/很有兴趣/真的很能解决痛点/很有前景，否则建议观望观望，毕竟太新的东西，AI 可能都不好写。

我举一些例子：
TS/JS 生态：Node -> Bun ； JS Date -> JS Temporal API ； Express/Nest -> Hono/Elysia ； esbuild 等构建、打包工具 -> vite (rolldown 驱动)； ESLint -> Oxlint/Biome ，Mermaid.js -> beautiful-mermaid ； Next -> TanStack Start…………
Python 生态：pip/venv/... -> uv ； Django/Flask -> FastAPI
排版：LaTeX -> Typst……

最近刚好了解了一点 mermaid 渲染。
如果你看过 [beautiful-mermaid]( https://agents.craft.do/mermaid) 和 mermaid.js 的对比，那你一定会觉得 mermaid.js -> beautiful-mermaid 的转变很值，它真的太好看了。
如果你知道以前服务端渲染 Mermaid 只能靠无头浏览器、模拟 DOM (jsdom) 的方案，那你就会感叹 [mermaid-rs-renderer]( https://github.com/1jehuang/mermaid-rs-renderer) 项目的出色，它真正做到了高性能、轻量级渲染 mermaid 。

@IndexOutOfBounds #4 不一定要用 D1 嘛，还可以用 Turso/Neon/Supabase 这些数据库

这主题、终端的颜值是真的高