Tag: 互联网

第三个网站 Read PDF Aloud 上线了。

12 月 14 日开工，1 月 1 日凌晨上线第一版，到今天把已知的 bug 和不完善的地方全部修改完，一共花了大半个月的时间，是我工期最长的一个站。

Read PDF Aloud 核心的功能和交互相比之前的网站都要复杂，所以踩了不少坑，都是经验不足导致的。

程序设计上，这次核心的交互逻辑是用面向对象的方式完成。

svelte 的状态管理方式天然适配面向对象范式，官网文档上也专门就 runes 在 class 内的使用做了介绍。这次真正使用面向对象，我也感受到了面向对象的优势，心智负担低，越写越顺手。

但这一切建立在对象设计合理的基础上。如果一开始规划有问题，后面少不了返工。我这次就经历了推到重来的过程。

第二个坑是 CloudFlare Workers。这次的涉及到 PDF 的文字提取和 TTS Api 的调用，所以需要一些简单的后端功能。我最初为 PDF 解析和 TTS Api 调用编写了相应的后端接口，都非常简单。

但是，在我第一次部署到 Worker 后，我就遇到了后端报错。一开始我还以为是我部署方式不对，后来我又怀疑是不是我用的库不适配 Worker 环境。

看完 Worker 的后台日志以后，我才发现，错误原因是 Error 1102: Worker exceeded resource limits。

简单来说，就是 Worker 对单次请求消耗的 cpu 时间有限制。免费版是 10ms，付费版是 30s。一些计算量比较大的任务，难免会占用更多 cpu 时间。当时我心都凉了，一度考虑要不要租个服务器。我还上网查了一下，发现踩到这个坑的，不止我一个。

后来理智说服了我，在没有赚钱的情况下，不能乱花钱。那就只能让用户体谅一下我的难处了，把 PDF 解析放在了用户的浏览器里。

剩下的坑就是一些交互设计上的问题了。

我一直觉得写 ui 最浪费时间，因为很容易陷入细节调试的地狱，我就看这个设计不顺眼，但是又不知道怎么改好，想太久，时间就白白浪费了。

之前做的网站交互都比较简单，这个问题不明显。这次的交互方式更复杂，尤其是阅读器的界面，我边想边写边改，来来回回拉扯了两天。昨天上线，发现交互有问题，又改了一天。现在这版算是没有大毛病了。

编程好难啊。

第二个工具站Glitch Text Generator。

这次算是做了一个有用的东西，能帮你把文字变成特殊的风格样式，比如说：

Glitch Text，可以变成：

₲łıꮏȼħ Ꮏєӿꮏ

ǤɫɨŁčꚕ ₸€ҳŁ

Ԍłıŧϲħ Ŧєӿŧ

𝓖𝓵𝓲𝓽𝓬𝓱 𝓣𝓮𝔁𝓽

还可以变成：

G̸̨̨̣̪͈͎̩͔̟̦͇̞̹͉̦̣͓͟͡l̞̰̭̘̯i̶̵̢̠͉̹͙̠͚̲̟̯̯͡͝t̷̛̛̜̲̫̝̱͚̳͇̠̮̬͖͎̭͙̤̯̝̠͍̘͖̤͎̘́̀̍͑͝҉̸̧̛͕̤͚͍͍̗̪̺̜̹̞̮̜͎ͦͨ͜͡͡ͅ͏̵̷̡̛̠̝̫̜̞̞͙̩̖̫̮̗͉̖͕̼̲̖̗̞̻̯͕̺̥̇̕͢c̵̢̡̦͚͈̻͕͕̭̭̤̘̣̙̺͙̬̟̖̭̥̻͗ͯͧͣ̀͢͝h̷̡̛̫̮͈̪̫̗̣̞̱̬̰͔̩͉̯͍̦̥̣̲̮̰̪͖̝̿̈́͊̀̀ͦ͘͟͜͜͞ ̡͇̫̳̞̳҉̨̹͉̟̳̹҉̨T̶̶̢̛͖̱͍̳̩̪̪̗̯͉͉̗̬̖͎̻͈̝͈̥̖̯̯̬̠̩͚̩͇͉͚͔͖̼̣̙̥̳̥̜̹̜̲̼̜̱͚̩͙̈͌͊͗̐̕͟͟͟͢͟͢͝͠͠͡ͅȩ̵͜͡͝x̮̻̱͎͕͜҉̶̷̷̷̷̶̢̢̧̯̘̣̣̝̙͓̬͈̰͙̜̤͎̮̜̪͇̼͇͙͈̖̻̠̟̝̥̘̫̥̟̮̠̮͉̝̪͖̬̬̺̤̙̞̯̤̯͍̪̟́̑ͣ͂̃̅͘͟͢ͅͅͅͅt̳̹̝͈͚҉̵̷̢̧̢̡̛̲̫͕̮̫̱͉͓̲̼̪̟̱̟̝͔̙̺̰̳̬͓̟̘͚̺͙͙̯͎̪̜̫̺̘̰͔̜̼͎̞̺͇̦͎͍̟̯̌ͫ̐ͯ̕͟͟͞͠ͅͅ҉̶̢̫̮͕͈̞̉̕͢͟͢

其原理是 Unicode 字符变体。

Unicode 字符集中有很多不同的字符，这些字符看起来很像，但实际上是不同的编码。

例如，字母 “A” 有多种变体，如 ”𝐀“（粗体 A）、”𝔄“（哥特体 A），还有”₳“（阿根廷比索符号）。

Unicode 字符集里有很多奇奇怪怪的字符，甚至还有古埃及象形文字 AKA 圣书体:

𓂀 𓆐 𓆡 𓆦

开发网站，在 cloudflare 买域名，用 Vercel 部署上线，添加 Google Analytics 和 Microsoft Clarity 的流量分析工具，最后集成 Google Adsense 代码。

满打满算用了两天时间 -> [2025-11-07_01-27-01]。

现在有一种追完了电视剧的无力感。

我能做的都做了，好像也没有那么复杂。除了开发网站，剩下的事情点点鼠标就能干。

我似乎有些迟钝。我才意识到做个人站长是一个什么样的行当。

怎么形容呢？这一行拼的其实是捕捉新需求的能力。

同行都是用赛博化身活跃在网络丛林里的赏金猎人。新鲜的需求就是猎物，在绝大多数时候是先到先得。或者花更多的时间和成本，兴许也能把老站压下去。

我现在就是一个刚刚在猎人公会注册成功的新猎人。手里的武器没有那么顺手，也不知道猎物在哪儿。

我现在自由了，可以用尽我所有的手段和方法。但是我也迷茫了，因为我还不知道有什么手段和方法可以利用。

这是真正的丛林世界，没有人会手把手教你怎么做。

毕竟每一个需求都是货真价实的流量和金钱。

谁会把这些拱手让人呢？

本人第一个出海工具站上线了。Elf name Generator 试水性质。明天把谷歌收录和必应收录的代码加上去，再加上一点数据监控的东西，看看有没有流量进来吧。

因为 vitest 只能用 node 运行，所以 不得不吧 easy-office-2 的里所有直接调用 Bun Api 的代码全部改成兼容 Node Api 的形式。

质疑 node，理解 node，使用 node，但是我依然讨厌 node。

Anton Putra在 YouTube 上发了一条视频，对比了 FastAPI (Python) 和 Node.js 的服务端性能表现。第一轮是测试单纯的 Get 请求，第二轮是测试 PostgreSQL 数据库的写入。两轮测试下来，Python 的综合性能表现差不多是 Node.js 的 1/10。

一般来讲服务端的性能瓶颈都在数据库 IO，很少会遇到 CPU 瓶颈。Anton Putra 测试过不少语言和服务端框架，Python 是为数不多能在测试中段就能撞上 CPU 性能墙的。而且撞墙以后也没有恢复，后半段被锁死在 50% 的 CPU usage 上跑完了全程，也不知道为什么。

FastAPI 已经是 Python 生态内性能比较好的框架了，我真不敢想 Django 这种老乌龟得慢成什么样。没有 jit，再加上 gil 的限制，Python 的性能真的……配不上它今天的江湖地位。

最关键的是，Node.js 在 JavaScript 生态内的性能也不突出，甚至可以说是比较拉胯的……

又心痒痒了，想试试用 htmx + Python 写写小项目。

不过 Python 的速度真不行，感觉 Bun 会好很多。

但是 Python 的 Ai 生态更好，JavaScript 生态圈内优质的 Ai 开源项目太少了。

好纠结啊。

大语言模型「懂不懂你」取决于它能获取到多少你有价值的数据。所以能无感，或低门槛的让你把有价值的数据交给它至关重要。

从这个角度看，微软、谷歌是最有潜力打造出真正基于大语言模型的生产力工具。前者有 office 这个全世界最受欢迎的办公套件，后者也有一套用户基数很大的办公套件，以及持续收集用户数据的搜索引擎和浏览器。

国内在这方面最有潜力的还是字节跳动。飞书虽然市占率不高，但是飞书已经基于豆包推出了知识问答，可以全量获取用户飞书内的所有聊天记录、文档、知识库等数据。

字节在这方面唯一的短板是不像 OpenAI 能做开放平台打通第三方服务（让腾讯和阿里把自己的数据开放给字节？这不可能），也不像 Google 本身就是一个小商业生态系统，用户能在里面满足一部分需求（现在已经打通了 Google 酒旅和 YouTube）。

腾讯也掌握了微信这个数据富矿，可惜微信里大部分都是聊天这种垃圾数据。企业微信和腾讯文档本身产品力不行，远远不如飞书好用。我甚至怀疑他们底层的数据架构也不如飞书开放灵活，想要打通、整合，可能还需要付出一点代价。

阿里有钉钉，但是我不清楚钉钉文档有多少人在用。在我的印象里，钉钉文档应该远不如飞书那么好用。而且钉钉文档的底层数据架构应该也不如飞书。现在钉钉文档 AI 也不能全量获取用户数据，还需要用户手动导入知识库，支持的格式也有限。

Astro 是个好框架，但是从实用性的角度上讲，彻底放弃 SSR 好像不太现实 🤔

最近两天在学 Astro。

Astro 的一大优势就是能静态生成网站。通过编译的方式，将 JavaScript 写的网站编译成只包含 HTML 和 CSS 的静态文件。不管是上到服务器用 Nginx 转发，还是放到静态网站托管平台，还是直接放 CDN，都能运行，不挑环境。

编译的好处就是能一处编译，处处运行。不依赖运行时和解释器。

现在 JavaScript 的运行时这么多，为啥没有人用 golang 写一个？然后继承 Golang 可以直接编译为二进制的优势，让 JavaScript 也能编译为二进制，做到一处编译，处处运行。