还好我是 24G 内存的，当时花的 1500 现在看来很值啊。

一般有两种方式：
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 这些数据库

这主题、终端的颜值是真的高 https://i.imgur.com/2spsghH.png

@vitality 而且优先使用 Bun
Node 很多 API 设计放到现在看，都不太合理。

Hono ！
Elysia 也很不错

@humanbait 因为现在大家都想一次编写代码，到处运行。节省时间与精力的追求，这在 AI 时代也不例外。

@DLOG 但如果是个人/小项目前期，使用原生反倒是浪费时间与精力、Token 。

Flutter + 1

DataGrip 很不错，UI 算是数据库管理工具中最好的
非商用免费

我就是 24G ，很庆幸当初没买 16G 。
因为我喜欢开很多标签页，再加上现在 AI IDE (Antigravity, VS Code, Cursor, Windsurf) 全是 Electron 应用，只有 Zed 是 Rust (GPUI) 应用；其他桌面软件也有很多是 Electron/Web-based/Java 方案（ Notion, Obsidian, QQ, DIscord...)，所以 24 G 也只能说是勉强够用，经常也有 Swap 。btw ，虽然有 Swap ，但确实一点都不卡。
JS 和 Java 真的害人不浅啊，凡是内存占用疯狂的日常应用，基本全都与这俩语言写的有关。

我站 TanStack Start ，部署的时候，运行时无关真的太重要了。
Next.js 太重了，开发时的内存占用非常夸张，也完全没有做到 Runtime agnostic （运行时无关）。想要部署在第三方都有局限性，不然为什么会有 [OpenNext]( https://opennext.js.org/) 项目的存在？

如果不需要保持长连接，即业务逻辑是短平快的 HTTP 请求， 可以使用 Serverless 方案。
Serverless 可供选择的有 Cloudflare Workers, ...
其他场景：可以考虑 fly.io, Railway 。这两者都支持 Docker 容器。
Cloudflare Workers, fly.io, Railway 这三者都提供一定量的免费额度。
关于出站流量费用（ Egress Cost ）：Cloudflare Workers 免出站流量费，按次数、CPU 实际占用时长（不含 await) 等规则计费。fly.io 和 Railway 的都还算便宜（至少比 GCP, AWS, Azure 便宜多了）。