用云服务，当你需要大内存（ 3 * 4G 就是 12G ）的时候很贵，免费的一般只能用一年，便宜的只能用一、两年，低配云服务器强行部署为 Kubernetes 节点的后果就是会很卡，可能你会看到 VPS 的内存占用变为 9x%，然后 load average 那三个数字 也很高，使用体验很差，ssh 上去或者 kubectl 执行个命令都要半天，建个 Pod 经常就是内存不足频繁重启，这些我都试过，所以用本地的就行，延迟地，配置高。

其实我觉得自己搭一台都差不多了（ DIY 主机搭配大内存不贵，还可以打游戏），或者干脆就用自己的 localhost ，现在的主流电脑都是 16G RAM 起步吧，本地建 3 台虚机作为 Kubernetes 节点足够了，可以在需要公网访问的时候再去找云服务器。

上一家公司做 toB 的产品，领导说他在的上一家公司的销售，就是你做的是依托💩都能给你卖出去，所以，大力出奇迹。我觉得 toC 也是一样的道理，毕竟我用过一些 toC 的软件也不怎么样，界面不友好也有小 bug ，但是因为它能解决我的需求，所以我也会捏着鼻子用。

多推广。

比如说你拿到的一个 PreSigned URL 是 https://oss.aliyun.com/xxx ，你就把它替换成 https://your-service.example.com/xxx ，然后你在 your-service.example.com 部署那个判断次数的 HTTP 应用。

@Dongxiaohao #25 虽然我没实现过，但感觉可以这样：你用 PreSigned URL （不知道 aliyun OSS 支持否），然后 PreSigned URL 的 hostname 部分指向你的一个服务，然后这个服务统计每一个 PreSigned URL 的请求次数，在此数之内，Http 302 重定向到真正的 PreSigned URL （就是 hostname 没被替换的那个），超过了次数返回错误，这样宽带不受你的服务器的限制。

自己部署吧，我个人觉得 Next.js 强大一点在于它的构建速度非常快，还提供了一个简单易用的 dynamic 动态加载功能，一般我都是 npm run build 等几秒然后直接 rsync 到 VPS ，整个过程感觉很流畅、自然。

部署到 Vercel 之前我也试过就是感觉构建时间太久了，push 上去之后，它有拉镜像、安装依赖、构建、打包镜像、发布这么一系列过程，自然比自部署的慢一些。

如果纯文字的话，替代品还是很多的呀，比如 Claude 和 Bard.

这种外行瞎指挥外加 UI 设计极其不专业也让前端心塞的一件事。

她不是在设计，她是在“管理”啊，老板让她指挥手下的人，她自己也享受指挥别人的过程。我们公司也是这样，UI 设计是后端兼职做的，丑的一匹，想到什么来什么（完全没有和已有风格保持协调、一致），UI 就是截图加上随手打的一两句话还带错别字。

Notion 满足你

题外话：IPv6 的其中一个愿景就是设计一个足够大、足够充裕的地址空间，使得设备与设备之间都可以点对点地直接互联（因为在这个充裕的地址空间里面大家都能分配到 IP 地址），所以普遍来说 ULA （私有地址）相对而言比较少见，大多数设备要么就是只有 fe 开头的 link local 地址，要么就是再加上多个 2 开头的 global unicast 地址（公网地址）。

因为 2000::/3 global unicast 地址是全球唯一的，所以理论上你的电脑可以用这个地址跟全球 IPv6 互联网的任何一台计算机双向通信（不管是谁主动发起连接，只需知道对方的 IPv6 地址），所以路由器/局域网网关设备出于安全起见一般都默认启动 IPv6 stateful firewall （只准局域网内的设备主动向外发起连接，不准广域网设备主动与局域网内的设备发起连接），这时地址虽然是公网地址，但从实际效果上看“相当于”内网地址。好处是阻挡了弱密码探测、爆破登录等安全风险，不过也不是绝对的安全。

WiFi 7 都出了，而且价格都是平民级的，所以，不如搜索一下 WiFi 7 路由器，另外 YWN3aWZp 也列出了两款新出的 WiFi 7 路由器。

如果层主对 IPv6 地址的实现方面感兴趣，还可以趁热打铁进一步了解下：

- NDP https://datatracker.ietf.org/doc/html/rfc4861
- DHCPv6 https://datatracker.ietf.org/doc/html/rfc8415
- SLAAC https://datatracker.ietf.org/doc/html/rfc4862
- IPv6 Prefix Delegation https://www.rfc-editor.org/rfc/rfc3633

等资讯。

事实上一个“设备”可以有多少个 IPv4/IPv6 地址几乎完全取决于软件（操作系统），跟硬件关系不大，操作系统是怎么把 IP 地址实现/分配到“设备”上的？在操作系统看来，每个链路层网络设备一般都有一个链路层地址（对于以太网设备来说是 MAC 地址），当操作系统收到当前来自设备所处的（一个或多个）以太网段（ Ethernet segment) 的 ARP 或者 NDP 查询时，它就回复，比如一个 ARP 查询是 "Who is 192.168.0.1, tell 192.168.0.101", 然后操作系统会回复 "192.168.0.101 is 82:bf:23:61:a2:95"，这样 192.168.0.101 这个地址就和 82:bf:23:61:a2:95 这个网卡关联了。

请参阅：

- RFC4291 https://datatracker.ietf.org/doc/html/rfc4291 ( IP Version 6 Addressing Architecture)
- RFC 4193 https://datatracker.ietf.org/doc/html/rfc4193 (Unique Local IPv6 Unicast Addresses)
- RFC3587 https://datatracker.ietf.org/doc/html/rfc3587 (IPv6 Global Unicast Address Format)
- IPv6 组播地址 https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

大体上来说，IPv6 地址分为单播地址、组播地址、任播地址，其中任播地址也是从单播地址空间里面分配的，单播地址细分为回环地址 (loopback), 全局单播地址 (global unicast) （ 2000::/3 前缀），IPv4 映射的 IPv6 地址（::ffff:<32bit ipv4 addr>), Link Local address （大部分是 fe80::/64 前缀），Unique Local Address (ULA) 一般用作本地、内网或者私有网络通信，ULA 一般是 fd00::/8 前缀。

一个“设备”（不管它是物理的 NIC 、 或者虚拟网卡也好）可以有多个 IPv6 地址。

也许是 sublime?

@dearliuliu #14 虽然我不是专职后端，但是我觉得从评价体系上来看，可能后端相对前端更有优势吧，对于简单的业务场景，前端需求更细更杂也更容易出 bug ，相反在简单业务场景下后端不那么容易出 bug （我没统计过）。

领导和客户都觉得前端做得好是理所应当的，比如“别人都能做这个效果”，那你说你作为前端你的价值在哪？按时按质按量交付前端实现不是本职要求吗？后端就不一样了，你可以说你的架构和代码实现多么高效，用有限的硬件资源实现了多大的性能指标（比如 qps 之类的），业务不复杂的时候后端写代码的时间占比非常低，我们公司的后端经常就是在设计、写文档、讨论等，他们可以有更多时间去往深了专研，比如 Linux 内核、计算机网络、分布式和一致性、高并发高可用、集群管理等，前端就只能苦哈哈的针对每一个交互细节去想怎么实现，对于每一种可能的用户输入情形都要考虑到，虽然很多效果有现成的库，但是代码量还是非常多，我们公司的设计还是后端兼任的，页面和页面直接有细小的差别（因为业务逻辑原因），这种细小差别积少成多导致代码也不好复用，陷入在屎坑里面前端是没有时间去解决那种能写到简历上的技术难题的，拿不出什么技术成就亮点，解决的都是很简单的问题，你在简历上怎么说。

我真的忍不住吐槽这么多，可能还有车轱辘话，但是低级前端（从职业上看）它就是一个屎坑，那种技术人都知道的前端大拿只是极少数。想做一款产品的话，业余时间纯粹自学（随写随学，什么不会搜什么），靠搜索引擎和 llm 是足够的呢。

你要是做自己的 side project 遇到问题了完全可以请教 llm ，一句话的事，llm 能给你直接能跑的代码。