Fuyeor

内容是自动从 Ф 同步而来的,以中文为主。

Fuyeorxiaoyuezi
2026-02-09

解决自定义语法和简繁转换引擎的问题:

````chain
考虑保护白名单

在添加新的 markdown 代码块格式后,需要修改简繁转换引擎,将它们显式添加到转换中。例如:

```rust
fn test_multiline_block_logic() {
// 1. 标准纯文本
assert_eq!(should_convert_block("```\n纯文本"), true);

// 2. JSON 转义
assert_eq!(should_convert_block("```\\n纯文本"), true);

// 3. 显式 text
assert_eq!(should_convert_block("```text\n内容"), true);

// 4. mermaid
assert_eq!(should_convert_block("```mermaid\ngraph"), true);

/…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/399

Fuyeorxiaoyuezi
2026-02-09

解决同步包含 SMILES 的内容到第三方平台时出现错误的问题...

````chain
发现同步错误

发现 SMILES 中包含的类似 markdown 的语法在同步到第三方平台上时会出现错误。出现错误的代码块链接(可能需要登录):

discord.com/channels/146049166

具体来说: `COC1=CC=C(N+ (fuyeor.com/=O)[O-])C=C1N+ (fuyeor.com/=O)[O-].NC1=CC=CC=C1>>O=N+ (fuyeor.com/[O-])C1=CC=C(NC2=CC=CC=C2)C(=C1)N+ (fuyeor.com/[O-])=O`

变成了:`COC1=CC=C(N+ (fuyeor.com/=O)[O-])C=C…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/398

Fuyeorxiaoyuezi
2026-02-08

時間軸版「瀏覽器 API `document.querySelector` 發展史」:

```chain
[x] 起源:jQuery 的革新
2006 年,John Resig 推出 jQuery。其獨創的 Sizzle 引擎讓開發者能用簡潔的 CSS 選擇器($)操控 DOM。

[x] 迴響:開發者的選擇
由於原生 API 太難用,jQuery 統治了 Web 十年。這種「用腳投票」的行為,終於讓冷酷的標準委員會感到了壓力。

[x] 繼承:標準化的降臨
W3C 與瀏覽器廠商決定「收編」這一智慧結晶。2013 年前後,querySelector 成為原生標準。

致敬:不應忘卻的姓名
雖然現在我們寫的是原生代碼,但每一行代碼裡,都跳動著 jQuery 的心臟。
```

—— Little Gecko Fuyeor, Ф fuyeor.com/t/397

Fuyeorxiaoyuezi
2026-02-06

如果我們在後端用 Intl.Segmenter 切詞,就可以實現想法內容字數統計。這樣,就可以實現對「碎片化」和「硬核」訊息流的調節... 以避免變成二元的「長文」或「碎片化社交媒體」。但應該考慮 Intl.Segmenter 內存佔用,因為它需要加載語言區域的規則數據。

這樣就可以透過滑塊(e.g., 50字 - 5000字)來決定看「碎片化吐槽」還是「深度長文」:

```
[ ◯───────◯───────◯ ]
碎片灵感 深度叙事 硬核长文
```

應該這樣嘛?

• 中文/日文/韓文 (CJK):按字符 (Graphemes) 計數。
• 英文/法文/俄文:按單詞 (Words) 計數。
• 泰文/無空格語言:按字符或詞邊界智能估算

但這樣可能會導致中文發佈者總是比其他語言主頁「wrote word」多,變得不公平。例如這篇中文故事 (fuyeor.com/thought/319)有 1075 字符,但它的英文版 (https://fuye…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/396

Fuyeorxiaoyuezi
2026-02-06

問題 FAQ

❝ 標題應該用 `## 標題` 還是加粗行,為什麼呀?

結論:chain 應該被視為一個內嵌組件,而不是文章結構的一部分,所以不應該用標題作為分割。

❝ 是否應該保留horizontal 參數?

結論:先砍掉,因為如果 chain 是橫向的,裡面又有 slide(也是橫向滑動),手指在屏幕上滑動時,瀏覽器會不知道用戶到底是想「滑動外層的時間軸」還是「滑動內層的卡片」,會造成手勢衝突。此外橫向的步驟條可以用 slide 來模擬。

❝ 我們是否應該添加 ```quote 語法,用於解決原生引用語法 `>` 麻煩的問題?這樣只需要寫一個代碼段即可引用一大片內容,無需每個開頭都寫 `>`?

結論:待考慮,但添加後會使 markdown 更易使用,因為:

• 兼容性 max:反引號在大部分鍵盤上都在左上角,而且通常不受全角/半角影響。相比之下,打:::或者 > 對於需要頻繁切換中英文的用戶來說更難。
• 提升編輯自由度:想把一段已經寫好的文字變成引用,用塊語法包裹…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/395

Fuyeorxiaoyuezi
2026-02-06

添加思考鏈/時間軸 markdown 語法

這是一種設計為展示思考過程或時間順序的格式,它將採用加粗的一整行作為標題分隔符。適用於展示思考過程、時間軸/順序、步驟等。

````markdown
```chain [參數]
標題 1

段落內容...

標題 2

段落內容...
```
````

❝ ✨ markdown 小提示:在代碼塊中包裹代碼塊語法 ``` 時,應該在外層使用四個反引號包裹代碼塊。

參數包括:

• order:開啟順序,每個標題前會自動添加數字。適用於展示步驟
• horizontal:將它改為橫向展示。是否保留存疑...因為已經有 slide 語法了,這似乎必要性不高。如果允許水平方向的 chain,內部出現 slide 會形成層層嵌套結構,容易混亂。初期先不支援水平方向的 chain
• fold:將它改成 accordion 手風琴樣式並默認折疊

—— Little Gecko Fuyeor, Ф fuyeor.com/t/393

Fuyeorxiaoyuezi
2026-02-04

跳转链接用 `go.fuyeor.com/redirect?url=` (go) 好,还是用 `depend.fuyeor.net/misc/v1/link/redirect?url=` (depend) 好,为什么呀?

用 go 的理由:

• 它存在 4 年多了
• 它是同 `fuyeor.com` 域名
• 看起来更简约、清晰

不用 go 的理由:

• go 看起来是 go,实际上是 php 写的,性能差
• 可以用新的 depend 后端集成 link 重定向服务,并且 link preview、redirect 共用一套黑名单
• 将 go 重定向服务修改为 depend 是无感操作
• SMILES 渲染、节日气氛会请求 `depend.fuyeor.net`。如果统一用 depend,可以减少对 go 域名的 DNS 解析、TLS 握手等,并且我们可以把 depend 加入 dns-prefetch 里

你觉得呢?*经讨论,重定向服务将会复用 depend 域…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/392

Fuyeorxiaoyuezi
2026-02-04

🟪 添加社交媒体外链卡片

YouTube 和其他网站的元数据/元信息任务,是否应该用 misc api(各网站通用、独立、高性能、依赖后端)解决?比如:

`depend.fuyeor.net/misc/v1/ext-`

这样,后端:

• 调用 cloudflare worker 去请求该网页的 html
• 解析出 ogp 标签,如果没有就回退 title/description
• 如果有 ogp 图片,就用 worker 下载?唔,这样就变成 2 次调用了...或调用 `images.weserv.nl` 裁剪并直接从这里下载
• 缓存链接的信息 hash 前两位文件到本地,3 个月内不再对相同链接重新请求 worker
• 前端对内容最后一个链接渲染外链卡片

这样就有了其他社交媒体的那种卡片(link preview card)。

✨ 细节处理

• 白名单:对部…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/391

Fuyeorxiaoyuezi
2026-02-01

Prisma v7 is not only significantly slower than v6, it also fundamentally changes how database connections are configured — from declarative schema/env-based configuration to runtime code.

The so-called “optimizations” are largely driven by edge-computing constraints (e.g. Vercel Edge), where shaving off a few milliseconds of cold start matters more than sustained throughput. To achieve this, Prisma shifted more execution and orchestration lo…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/390

Fuyeorxiaoyuezi
2026-01-30

“母亲节”在不同国家日期不同:

| 国家 | 母亲节日期 |
|------|-----------|
| 中国、美国、加拿大、日本等 | 5月第二个星期日(2026年:5月10日)|
| 瑞典、挪威 | 5月最后一个星期日(2026年:5月31日)|
| 英国 | 四旬斋第四个星期日(2026年:3月15日)|
| 法国 | 5月最后一个星期日(若与 Pentecost 冲突则顺延)|

在没有明确用户地域、又无法动态适配 locale 的情况下,硬编码“母亲节”这种高度本地化的节日,容易造成体验不一致甚至误导:

• 瑞典 IP 搜索 Google 告诉我 5/31;
• 中国用户期待是 5/10;
• 英国用户可能根本不过这天;

结果就是:无论怎么选,总会有人觉得“今天不是母亲节啊?” 😅

通过时区判断...?但韩国是母亲节兼父亲节,而节日气氛的母亲节文件夹里没有相关素材。而且母亲节日期太多了。

```js
const tz = Intl.DateTimeForma…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/387

Fuyeorxiaoyuezi
2026-01-29

Chrome 移動版的體驗好菜,關閉標簽頁後,會有一個帶「undo」的 toast 通知條持續全局顯示在下面,且沒有關閉按鈕。如果被關閉的標簽頁標題比較長,這個通知條的高度也會隨之變高,配合持續顯示,就會長期遮擋網頁上的元素,導致網頁功能無法正常使用 (比如底部的聊天框)

而且,有時候在 pwa 應用 (既:在 Chrome 點擊「add to home screen」安裝的網站) 中,如果網頁是其他語言,Chrome 還可能會在頂部顯示一個翻譯通知條,同樣這個也不能關閉,但它和前者的唯一區別就是——滑一下它就動一下,但永遠不會被主動關閉 (但 Chrome 瀏覽器裡的翻譯提示是可以關閉的,只是 pwa 裡不能關閉,只能等它主動消失)

此外,「tap to see search results」也是干擾項之一。只要點擊文字就會從底部滑出 sheet menu 顯示這個詞的意思或者提示去搜索。然而,大部分時候選中文字只是誤觸或複製,並不是想要搜索這個詞。

—— Little Gecko Fuyeor, Ф fuyeor.com/t/386

Fuyeorxiaoyuezi
2026-01-28

```abc
X:1
T:The Legacy Jig
M:6/8
L:1/8
R:jig
K:G
GFG BAB|gfg gab|G3 BAB|d2A AFD|
GFG BAB|gfg gab|age edB|1 dBA G2D:|2 dBA G3|]
```

—— Little Gecko Fuyeor, Ф fuyeor.com/t/385

Fuyeorxiaoyuezi
2026-01-27

我支援長字數的初期目的其實是環保!當然也有反對碎片的考量。我覺得,限制幾百字符貼文長度毫無意義,因為用戶不一定會因此而精簡內容,反而會用 thread 發好幾個帖子。這樣:

• 如果發錯了,就要全部刪除重發。特別是不支持修改的那些社交媒體。這會浪費注意力,因為可能錯的內容已經推送了,用戶點進去卻是已刪除。
• 如果要刪除串文,往往需要多次操作,對每篇貼文都要點擊菜單 →「刪除」→ 確認,額外浪費時間。
• 資料庫存一行顯然比存好幾行更環保。因為每行都有索引成本呀。可能一個帖子的元信息比它本身還多 (如果用戶就發了幾個字母)。
• 用戶需要浪費更多時間排版,因為他們不僅需要尋找合適的分割點、調整字數以滿足限制,還要額外考慮在 thread 裡上下文連貫的美觀性、首貼還可能需要放一個查看串文 (thread) 的引導。
• 用戶還可能會因為平台限制而放棄優化排版,直接在超限的地方複製粘貼到下一個 thread 的貼文裡,顯得特別碎片化。就像想說一句話被頻繁打斷一樣。
• AI 翻譯時…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/383

Fuyeorxiaoyuezi
2026-01-27

我設計的 smiles 用法是 ```smiles 開頭的代碼塊,但實際上也需要在行間使用結構式,所以應該再設計一種內聯語法。

`[smiles]cco[/smiles]` 這種風格怎麼樣呀?我也不知道這是什麼風格。啊!gemini 說它是 bbcode 風格。

誰更好呀?但我覺得這兩種都有些麻煩...但短的又擔心和其他語法衝突,例如 latex 的`$`或者內聯代碼。

最好還得支援自定義高亮結構?比如使用者可能會想高亮一部分,而 chemistry api 支援,但如果社交媒體裡卻不支援就很奇怪。

雖然 bbcode 寫起來麻煩,可我覺得它實現這個功能確實是最簡單、最優雅的誒...

```
[smiles highlight="結構"]分子式[/smiles]
```

雖然只打一個單獨的 smiles 很難,但如果一旦需要擴展元信息就會立刻變得很簡單:

• 可以很方便地加屬性,這樣就可以把精心設計的 chemist…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/382

Fuyeorxiaoyuezi
2026-01-27

🚨 Update: Cloudflare support later confirmed that the bucket can be safely deleted this month without triggering any additional charges ↓

❝ Hi,
❝ I completely understand your concern about unexpected charges—we want to make sure everything is handled smoothly for you.
❝ You can safely delete your R2 bucket yourself, and it will not result in any further charges this month. If you have any other questions, please don't hesitate to reach out!

—— Little Gecko Fuyeor, Ф fuyeor.com/t/381

Fuyeorxiaoyuezi
2026-01-25

Cloudflare R2 Infrequent Access: A Hidden Trap Charge

Two days ago, I was charged $9 for 32 Class A operations on R2 Infrequent Access, which I believe is fundamentally unreasonable.

After contacting support, I received the following response:

❝ Charges for R2 are based on usage, and even minimal activity can incur usage-based costs… Because of this usage, we are unable to process a refund.

After that, I immediately requested a…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/380

Fuyeorxiaoyuezi
2026-01-24

In the classical sense, — the virtue of “empathy, gentleness, respect, frugality, and humility” — is on the verge of extinction on today’s internet.
Let us continue to uphold and defend it here, in Ф.

Humanity is like personal integrity or civility: some people have more of it, some less, and some none at all—but it cannot be assumed that no one possesses it anymore.

Definition: Humanity is not only about being nice; it is about de…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/378

Fuyeorxiaoyuezi
2026-01-24

Java 程式的執行過程就像在燉一鍋「老火靚湯」,過程極其緩慢且折騰:

• 生火: 程式啟動時,JVM(Java 虛擬機)需要先加載大量的類別、初始化記憶體,還得灌滿一整缸熱水(堆內存)才能開火,這就是「生火」的過程。
• 熬煮: Java 程式碼一開始是「字節碼」, 會在運行時邊跑邊觀察(文火慢燉字節碼),把熱點代碼編譯成機器碼(有些地方用戶經常點,就開始猛火爆炒字節碼)。這個「邊跑邊編譯」的過程,就像在鍋裡反覆「熬煮」那些字節碼,直到它變成熟的(機器碼)。

而且無論程式多小,都必須帶著一個巨大的「鍋」(JVM 運行環境)才能跑。而 Rust/LLVM 是「直接燒製」,代碼在出廠(編譯階段)就已經是成品,一上場就能發揮 100% 的性能,不需要在伺服器裡現場「熬煮」,也不需要帶鍋。

字節碼在 JVM 裡尖叫:「我可是 Java 親生的!JVM 卻一邊靠我運行,一邊又拼命優化、驗證、甚至拋出 `StackOverflowError` 折磨我……咱倆本是一體,…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/377

Fuyeorxiaoyuezi
2026-01-24

Ε=(´ο`*))) 支持我的滑動塊(slide block)設計...

滑動塊是我很喜歡的格式,內容可以分成好幾塊並列,查看時可以左右滑動,用於對比。這讓內容不再是強線性的,對比也可以收納到一塊,不佔據內容長度空間。

雖然這個功能很早就支持了,但那是另一個以 HTML 為主的問答網站 answers。在以 markdown 為主的新網站 www 裡,還沒有這個功能耶...

設計外層語法格式

我將它設計為代碼塊,但標籤是 slide,這樣會有統一的體驗,與以前的 mermaid 和其他代碼一致,也會與將來推出的化學結構式(smiles)一致。這樣:

• ​mermaid 解決了邏輯流。
• latex 解決了精密算式。
• ​highlight 解決了代碼可讀性。
• ​slide 解決了「對比與節奏」。有些內容並列看才清晰(比如 A/B 方案、不同語言的對照),強行上下排列會破壞閱讀流,而 Slide 塊完美解決了這個物理世界的排版痛點。
• smiles 解決了表達化…

—— Little Gecko Fuyeor, Ф fuyeor.com/t/376

Client Info

Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst