@vitality 今年内昆明、青岛局肯定会上，但海口局可能得明年去了，南宁局更是杳无音讯。

国际出入局带宽或许并非最紧缺的资源。深港两地陆地接壤，陆缆的建设成本与周期远低于海缆——可以说，只要想，带宽想要多高就能多高。

真正的瓶颈在于 GFW 的审查带宽。所有出入境公网流量均须经 GFW 审查，再行分发，而这一步骤由国际通信业务出入口局承担。即便底层带宽充裕，若审查带宽不足，整体吞吐照样受限。

目前承载全业务的国际通信业务出入口局仅设于北上广三地，未来还会有昆明/青岛，以及海口、南宁。

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

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

@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 算是数据库管理工具中最好的
非商用免费