https://jianghu.zturn.top/feed.xml 2026-04-24T02:13:33.003Z 以系列目录组织的长文站点，提供可爬取的静态页面与章节导航。 https://jianghu.zturn.top/series/browser-jianghu/browser-jianghu-00-intro.html 2026-04-12T09:35:45.385Z 2026-04-12T09:35:45.385Z

浏览器江湖：真正塑造 Web 的力量，不只在规范里，更在谁控制默认入口和实现现实 今天所有前端、所有普通用户，几乎每天都在打开浏览器。 可很少有人会先问一句： 为什么浏览器看起来只是一个“看网页的工具”，最后却会变成整个 Web 世界里最有权力的那一层？ 为什么同样一份开放标准，

https://jianghu.zturn.top/series/browser-jianghu/browser-jianghu-01-browser-became-the-gateway-to-the-web.html 2026-04-12T09:35:45.386Z 2026-04-12T09:35:45.386Z

浏览器江湖（一）：浏览器为什么从一开始就不是工具，而是 Web 的入口王座 01｜这篇真正要先立住的，不是“Mosaic 很早、Netscape 很火”，而是为什么浏览器从一开始就天然带着入口权 今天回头看浏览器，很容易把它想成一层中性的外壳： 把网页显示出来 提供地址栏 给用户

https://jianghu.zturn.top/series/browser-jianghu/browser-jianghu-02-browser-war-was-about-default-control.html 2026-04-12T09:35:45.386Z 2026-04-12T09:35:45.386Z

浏览器江湖（二）：第一次浏览器大战，争的不是功能，而是谁能当默认入口 01｜如果把第一次浏览器大战写成“IE 和 Netscape 比谁功能更多”，就会把最狠的一层漏掉 很多人回忆浏览器大战，最容易记住的是这些画面： Netscape 很早很强 IE 后来追上来 两边都在加功能

https://jianghu.zturn.top/series/browser-jianghu/browser-jianghu-03-when-one-browser-won-the-web-stalled.html 2026-04-12T09:35:45.386Z 2026-04-12T09:35:45.386Z

浏览器江湖（三）：为什么 IE 打赢了战争，Web 却反而慢了下来 01｜这篇最该先立住的，是一个特别反常识的问题：为什么浏览器战争分出胜负之后，开放 Web 没有更快进步，反而像被拖慢了 按很多人的直觉， 竞争结束之后，世界应该变简单。 标准更容易统一。 开发者不用再为多套浏览

https://jianghu.zturn.top/series/browser-jianghu/browser-jianghu-04-acid-tests-turned-standards-into-public-exams.html 2026-04-12T09:35:45.386Z 2026-04-12T09:35:45.386Z

浏览器江湖（四）：一张笑脸和一张成绩单，怎么把浏览器厂商逼上公开考场 01｜Acid2 和 Acid3 最厉害的地方，不是它们测了多少特性，而是它们把“标准支持”变成了所有人都看得懂的公开考试 标准这件事，平时有一个天然弱点： 它太专业。 规范文档厚。 实现细节杂。 互操作问题往

https://jianghu.zturn.top/series/browser-jianghu/browser-jianghu-05-chrome-won-with-speed-and-release-rhythm.html 2026-04-12T09:35:45.386Z 2026-04-12T09:35:45.386Z

浏览器江湖（五）：Chrome 为什么不是单靠更快，而是靠整套新秩序重新夺权 01｜如果把 Chrome 的崛起写成“Google 做了个更快的浏览器”，那就会把真正发生的那次秩序改写写小了 Chrome 刚出来时，最容易被记住的是“快”。 更快的 JavaScript。 更快的

https://jianghu.zturn.top/series/browser-jianghu/browser-jianghu-06-blink-fork-changed-engine-politics.html 2026-04-12T09:35:45.387Z 2026-04-12T09:35:45.387Z

浏览器江湖（六）：Blink fork 为什么不是换个名字，而是引擎治理公开分家 01｜Blink fork 最容易被写浅的地方，就是把它理解成一次普通的工程分叉 表面上看，这件事很像技术新闻： Google 从 WebKit fork 出了 Blink。 Chrome 从此不再

https://jianghu.zturn.top/series/browser-jianghu/browser-jianghu-07-when-open-web-started-leaning-on-one-engine-again.html 2026-04-12T09:35:45.387Z 2026-04-12T09:35:45.387Z

浏览器江湖（七）：为什么 Chromium 时代看起来更开放，却又更像回到单引擎现实 01｜这一篇最值得先摆出来的矛盾是：今天浏览器品牌看起来很多，为什么很多人反而越来越担心“现实里其实又只剩一个主引擎” 如果你只看表面， 今天的浏览器世界好像比 IE6 时代健康得多。 品牌很多

https://jianghu.zturn.top/series/browser-jianghu/browser-jianghu-08-manifest-v3-redrew-browser-power-boundaries.html 2026-04-12T09:35:45.388Z 2026-04-12T09:35:45.388Z

浏览器江湖（八）：Manifest V3 为什么像一场“为了安全”的收权实验 01｜写到这里，最值得追问的已经不是“浏览器还在不在竞争”，而是“浏览器厂商今天还能替用户和开发者决定多少边界” 前面几篇一路讲下来， 我们已经看到浏览器权力是怎么一层层长出来的： 它先成了 Web 入

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-00-intro.html 2026-04-13T06:04:11.072Z 2026-04-13T06:04:11.072Z

跨端江湖：一套代码到处跑不是胜利史，而是一代代重新分配复杂度的历史 今天很多人已经把这些词当成了默认现实： React Native Flutter Electron PWA 小程序 Tauri 好像只要产品一上多端，团队就一定会认真讨论一次： 能不能少写几份代码？ 可很少有人会

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-01-apple-killed-flash-or-third-party-runtime-power.html 2026-04-13T08:18:00.771Z 2026-04-13T08:18:00.771Z

跨端江湖（一）：苹果杀死的到底是 Flash，还是开发者绕开平台的权利 01｜Flash 当年到底像不像“真跨端”？ 今天回头看 Flash，很多人第一反应往往都是： 老插件 网页小游戏 烦人的广告 最后被 HTML5 淘汰 这当然没错。 可如果你只用这个视角看它，就会把 Fla

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-02-why-web-app-pain-was-in-webview.html 2026-04-13T08:16:17.246Z 2026-04-13T08:16:17.246Z

跨端江湖（二）：为什么“网页做 App”最痛的时候，不在 JavaScript，而在 WebView 01｜PhoneGap 一出场就很诱人 Flash 那条线的问题太大了。 它想统一的层太高， 也太像在和平台抢解释权。 于是后来的跨端路线很快换了一个思路： 我不自己再造一个完整

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-03-react-native-shrank-the-promise.html 2026-04-13T08:16:27.003Z 2026-04-13T08:16:27.003Z

跨端江湖（三）：React Native 最重要的历史，不是多像原生，而是它主动放弃了“写一次到处跑” 01｜React Native 到底是从哪里切进来的？ 写到这里，跨端这条线已经很清楚了。 Hybrid 的最大吸引力是： Web 团队现成可用 开发速度快 复用率高 可它最深

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-04-pwa-ran-into-app-store-power.html 2026-04-13T08:16:33.244Z 2026-04-13T08:16:33.244Z

跨端江湖（四）：PWA 最尴尬的地方，不是做不到像 App，而是一旦太像 App 就会碰到 App Store 01｜PWA 真是在做“网页增强”，还是在碰入口？ 写到这里， 跨端这条线其实已经分出两种非常不同的现代答案了。 一种是 React Native 这种： 接受原生宿主

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-05-electron-won-by-reducing-org-friction.html 2026-04-13T08:16:43.598Z 2026-04-13T08:16:43.598Z

跨端江湖（五）：Electron 为什么明知很重，还是成了桌面跨端的现实答案 01｜到了桌面端，重反而没那么致命 到了桌面端， 跨端这件事的气质又突然变了。 因为桌面应用和移动应用面对的现实根本不一样。 移动端通常更敏感的是： 电池 帧率 触摸反馈 系统资源预算 而桌面端很多时候

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-06-why-cross-platform-has-no-final-form.html 2026-04-13T08:16:48.817Z 2026-04-13T08:16:48.817Z

跨端江湖（六）：跨端为什么不会终结，只会继续回到选择性妥协 01｜跨端总会一次次回来 如果把前五篇连起来看， 你会发现一件特别明显的事。 这些路线看上去差别很大： Flash Hybrid React Native PWA Electron 它们的宿主不同， 时代不同， 卖点不同

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-07-flutter-did-not-want-ui-explained-by-host-controls.html 2026-04-13T08:16:54.612Z 2026-04-13T08:16:54.612Z

跨端江湖（番外一）：Flutter 真正想解决的，不只是跨端，而是宿主控件这层旧妥协 01｜Flutter 干脆不想再借宿主了 主线第三篇写到 React Native 时， 整条跨端线已经有了一个非常现代、也非常成熟的姿态： 承认宿主重要 承认差异不会消失 尽量共享逻辑和心智

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-08-mini-programs-turned-cross-platform-into-rented-capability.html 2026-04-13T08:16:59.695Z 2026-04-13T08:16:59.695Z

跨端江湖（番外二）：中国跨端最特别的地方，不是技术统一，而是平台先把边界写死了 01｜中国最后长出了和 PWA 完全相反的一条路 主线第四篇写 PWA 时， 最重要的一层是： 开放 Web 一旦想重新长成应用入口，就会碰到平台边界。 可如果把视角转到中国互联网语境， 你会发现这里

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-09-tauri-repriced-the-desktop-runtime-tax.html 2026-04-13T08:17:03.979Z 2026-04-13T08:17:03.979Z

跨端江湖（番外三）：Tauri 想省下的，不只是 Chromium，而是一整笔桌面运行时税 01｜Electron 之后，行业突然开始嫌税重了 主线第五篇讲 Electron， 最重要的一层判断是： 很多企业买的不是最省资源的程序，而是最省组织摩擦的程序。 可历史从来不会停在这里

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-10-capacitor-made-hybrid-pragmatic-again.html 2026-04-13T08:17:08.947Z 2026-04-13T08:17:08.947Z

跨端江湖（番外四）：Hybrid 没有死，它只是终于不再假装自己像原生 01｜Hybrid 都被骂成这样了，还没死 主线第二篇已经把 PhoneGap / Cordova 那条线最痛的地方写得很清楚了： WebView 不稳 宿主碎片化严重 体验账单越来越藏不住 照理说， 这条路

https://jianghu.zturn.top/series/cross-platform-jianghu/cross-platform-jianghu-11-react-native-new-architecture-was-a-bridge-rewrite.html 2026-04-13T08:17:24.975Z 2026-04-13T08:17:24.975Z

跨端江湖（番外五）：React Native 后来做的，不只是提速，而是承认旧桥接本身就是问题 01｜旧桥接时代，后来到底补了多少票？ 主线第三篇里， React Native 最重要的一句已经立住了： 它真正成熟的地方，不是更像原生，而是主动承认原生差异不会消失。 可如果只写到

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖：这门语言不是写出来的，是一路吵出来的.html 2026-04-12T09:35:45.388Z 2026-04-12T09:35:45.388Z

CSS 江湖：这门语言不是写出来的，是一路吵出来的 很多人学 CSS，是从选择器、盒模型、定位、Flexbox 开始的。 可如果你把时间往回拨，会发现它的开场根本不像一门“样式语言”的诞生史。 它更像一出很长的连续剧。 1994 年，Web 还更像文档网络，大家先吵的是：网页到底

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖（一）：谁有权给网页化妆？.html 2026-04-12T09:35:45.390Z 2026-04-12T09:35:45.390Z

CSS 江湖（一）：谁有权给网页化妆？ 01｜这场架，先不是技术架 很多人今天回头看 CSS，会觉得它不过是一门样式语言。 选择器、属性、值、花括号。 可在 1994 年 ，CSS 还没出生的时候，大家先吵起来的，并不是语法该怎么写。 而是一个更原始的问题： 网页到底该听谁的？

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖（二）：标准还没定，微软和网景已经打起来了.html 2026-04-12T09:35:45.391Z 2026-04-12T09:35:45.391Z

CSS 江湖（二）：标准还没定，微软和网景已经打起来了 01｜这一回，敌人不是语法，是分裂 第一篇里，CSS 还像个年轻提案，站在会议门口，手里攥着几页纸。 到了 1995 年底 ，门开了。 门里不是程序员论坛，不是爱好者邮件列表，而是 HTML Editorial Review

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖（三）：CSS2 越写越大，浏览器越跑越偏.html 2026-04-12T09:35:45.391Z 2026-04-12T09:35:45.391Z

CSS 江湖（三）：CSS2 越写越大，浏览器越跑越偏 01｜1998 年，CSS 突然开始“想要一切” 如果说 CSS1 还像个刚学会走路的小孩，先把字体、颜色、间距这些最基本的体面撑起来；那到 1998 年 ，它的野心已经肉眼可见地膨胀了。 1998 年 5 月 12 日 ，

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖（四）：一张笑脸，逼得浏览器厂商连夜补课.html 2026-04-12T09:35:45.392Z 2026-04-12T09:35:45.392Z

CSS 江湖（四）：一张笑脸，逼得浏览器厂商连夜补课 01｜2005 年，Web 标准阵营决定不讲大道理了 写到第三篇，CSS 已经走到一个很尴尬的阶段。 规范在修，浏览器在追，开发者在中间受夹板气。 这时候再发一篇长文，讲“互操作很重要”“大家应该尊重标准”，其实已经没什么用了

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖（五）：CSS3 越红火，前端越像在扫雷.html 2026-04-12T09:35:45.393Z 2026-04-12T09:35:45.393Z

CSS 江湖（五）：CSS3 越红火，前端越像在扫雷 01｜人人都在喊 CSS3，可谁也说不清 CSS3 到底是什么 Acid2、Acid3 把浏览器厂商抽得不轻之后，前端圈迎来了一段很热闹的日子。 新东西开始一波接一波往外冒： 圆角、阴影、渐变、变形、过渡、动画、多列、弹性布局

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖（六）：2012 年前缀危机，差点把开放 Web 拖回 IE6 时代.html 2026-04-12T09:35:45.393Z 2026-04-12T09:35:45.393Z

CSS 江湖（六）：2012 年前缀危机，差点把开放 Web 拖回 IE6 时代 01｜最荒唐的一幕，不是 -webkit- 到处都是 而是有一天，别的浏览器开始认真讨论： “要不，我们也支持 -webkit- 吧。” 你第一次听到这句话，多半会愣一下。 因为前缀这东西，本来就是

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖（七）：标准都写出来了，为什么主流引擎就是不想实现.html 2026-04-12T09:35:45.394Z 2026-04-12T09:35:45.394Z

CSS 江湖（七）：标准都写出来了，为什么主流引擎就是不想实现 01｜有些标准死得很安静 前面几篇写的，大多是那种热闹的冲突。 有人吵。 有人骂。 有人在邮件列表里掀桌子。 可 Web 标准史上，还有一种更冷的死法： 规范在。文档在。草案也在。就是主流引擎越来越不想碰。 这种死法

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖（八）：为什么有些 CSS 熬成了标准，有些却死在半路上.html 2026-04-12T09:35:45.395Z 2026-04-12T09:35:45.395Z

CSS 江湖（八）：为什么有些 CSS 熬成了标准，有些却死在半路上 01｜写到最后，真正的问题已经不是某个属性了 前七篇一路写下来，表面上看，主角换了很多次。 有时候是 CSS1 。 有时候是 CSS 2.1 。 有时候是 Acid2 、 前缀危机 、 CSS Regions

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖（番外一）：Grid 为什么不是更早来到 Web.html 2026-04-12T09:35:45.396Z 2026-04-12T09:35:45.396Z

CSS 江湖（番外一）：Grid 为什么不是更早来到 Web 01｜2011 年 W3C 就把 Grid 挂上去了，可它并没有立刻改变 Web 如果你只看今天，会很容易误会 CSS Grid 是一种顺理成章的能力。 可时间线一点都不“顺理成章”。 W3C 在 2011-04-07

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖（番外二）：为什么 `·has()` 会难产二十年.html 2026-04-12T09:35:45.397Z 2026-04-12T09:35:45.397Z

CSS 江湖（番外二）：为什么 :has() 会难产二十年 01｜WebKit 自己都承认：这件事在 CSS 世界里讨论了二十多年 :has() 真正扎人的地方，不是它终于来了。 而是它来得实在太晚。 WebKit 在 2022 年发布 :has() 支持说明时，开头几乎是摊牌式

https://jianghu.zturn.top/series/css-jianghu/CSS 江湖（番外三）：为什么 `container queries` 曾被说成“不可能”.html 2026-04-12T09:35:45.398Z 2026-04-12T09:35:45.398Z

CSS 江湖（番外三）：为什么 container queries 曾被说成“不可能” 01｜“这不可能，别再问了” 这大概是浏览器曾经给过最直白的回答之一 container queries 这条线的戏剧性，恰恰在于它不像一个听上去离谱的需求。 相反，它太合理了。 合理到很多前

https://jianghu.zturn.top/series/database-jianghu/database-jianghu-00-intro.html 2026-04-15T04:00:19.547Z 2026-04-15T04:00:19.547Z

数据库江湖：数据库史首先是谁定义数据秩序的历史，不只是存储技术进化史 今天很多团队一打开项目，几乎都会看到： schema.sql 或一串 migration 文件 代码里堆着 ORM 模型、索引声明和事务边界 配置里写着主从、只读、副本、连接池、重试 文档里讨论 MySQL、P

https://jianghu.zturn.top/series/database-jianghu/database-jianghu-01-relational-order-and-commercial-databases.html 2026-04-15T04:00:24.808Z 2026-04-15T04:00:24.808Z

数据库江湖（一）：关系型数据库真正卖出去的，不只是表和 SQL，而是企业秩序 上一篇数据库江湖：数据库史首先是谁定义数据秩序的历史，不只是存储技术进化史先把总问题立住了：数据库从来不是中性的存储容器，而是把 正确性、扩展性与运维复杂度 重新分配的制度机器。 所以第一篇不能急着谈

https://jianghu.zturn.top/series/database-jianghu/database-jianghu-02-how-mysql-democratized-databases.html 2026-04-15T04:00:30.428Z 2026-04-15T04:00:30.428Z

数据库江湖（二）：MySQL 真正改变的，不只是价格，而是数据库掉进了每个开发者手里 上一篇数据库江湖（一）：关系型数据库真正卖出去的，不只是表和 SQL，而是企业秩序写到，关系型数据库之所以长期稳固，不只是因为表、SQL 和事务。 它更深的胜利，是成为了企业世界对“正式数据”的

https://jianghu.zturn.top/series/database-jianghu/database-jianghu-03-why-postgresql-kept-returning.html 2026-04-15T04:01:19.450Z 2026-04-15T04:01:19.450Z

数据库江湖（三）：PostgreSQL 总在旧秩序快失灵时被重新想起，因为它一直在给关系型续命 上一篇数据库江湖（二）：MySQL 真正改变的，不只是价格，而是数据库掉进了每个开发者手里写 MySQL，重点不在“它最好”，而在“它把数据库普及了”。 可数据库世界并不会因为普及就只

https://jianghu.zturn.top/series/database-jianghu/database-jianghu-04-nosql-broke-the-one-order-myth.html 2026-04-15T04:01:25.354Z 2026-04-15T04:01:25.354Z

数据库江湖（四）：NoSQL 真正拆掉的，不是 SQL，而是“一种秩序统治所有数据”的幻觉 写完数据库江湖（三）：PostgreSQL 总在旧秩序快失灵时被重新想起，因为它一直在给关系型续命，接下来就得进入数据库史里最容易被写成口号大战的一段。 因为一提 NoSQL，中文世界立刻

https://jianghu.zturn.top/series/database-jianghu/database-jianghu-05-newsql-brought-sql-back-to-distributed-systems.html 2026-04-15T04:01:30.628Z 2026-04-15T04:01:30.628Z

数据库江湖（五）：NewSQL 不是回到过去，而是大家终于承认还想要 SQL、事务和熟悉的秩序 上一篇数据库江湖（四）：NoSQL 真正拆掉的，不是 SQL，而是“一种秩序统治所有数据”的幻觉写 NoSQL，重点不是“它赢了”，而是它拆掉了数据库行业长期维持的单一正统幻觉。 可幻

https://jianghu.zturn.top/series/database-jianghu/database-jianghu-06-cloud-databases-moved-power-to-platforms.html 2026-04-15T04:01:35.594Z 2026-04-15T04:01:35.594Z

数据库江湖（六）：云数据库卖的从来不只是托管，而是把控制权悄悄搬回平台手里 写到这里，顺着数据库江湖（五）：NewSQL 不是回到过去，而是大家终于承认还想要 SQL、事务和熟悉的秩序往下看，数据库世界已经经历了几轮很典型的摆动： 关系型把秩序集中起来 MySQL 把数据库普及给

https://jianghu.zturn.top/series/database-jianghu/database-jianghu-07-database-legacies-and-new-lockins.html 2026-04-15T03:52:12.339Z 2026-04-15T03:52:12.339Z

数据库江湖（七）：数据库没有终局，只有一轮轮把复杂度换个承担者的旧账重写 从数据库江湖：数据库史首先是谁定义数据秩序的历史，不只是存储技术进化史一路写到数据库江湖（六）：云数据库卖的从来不只是托管，而是把控制权悄悄搬回平台手里，到了收束篇，最容易偷懒的方式，是做一张“数据库演化路

https://jianghu.zturn.top/series/framework-jianghu/framework-jianghu-00-intro.html 2026-04-12T09:35:45.399Z 2026-04-12T09:35:45.399Z

框架江湖：前端框架史不是自然进步，而是一轮轮重新分配前端权力 今天你随便打开一个认真一点的前端项目，十有八九都会默认看到这些东西： 组件目录 路由目录 状态管理或数据获取约定 官方推荐脚手架 TypeScript SSR / SSG / hydration 一类词 很多时候，我们

https://jianghu.zturn.top/series/framework-jianghu/framework-jianghu-01-why-libraries-had-to-rise-before-frameworks.html 2026-04-12T09:35:45.399Z 2026-04-12T09:35:45.399Z

框架江湖（一）：库先统一了浏览器战场，框架才有机会争夺更高层秩序 01｜如果只看今天，你很容易误以为前端一开始就该有框架 今天很多人刚接触前端应用开发时，心里默认的起点已经是： 先选框架 再起脚手架 再按官方推荐的目录、路由、组件和数据获取方式往下走 所以很容易倒过来想象历史：

https://jianghu.zturn.top/series/framework-jianghu/framework-jianghu-02-mvc-mvvm-tried-to-discipline-browser-apps.html 2026-04-12T09:35:45.399Z 2026-04-12T09:35:45.399Z

框架江湖（二）：当浏览器开始像应用，Backbone、Knockout、Ember、AngularJS 都在抢架构解释权 01｜库不再够用的那一刻，前端第一次需要的是“宪法” 上一篇讲到， jQuery 这类库先统一了浏览器现实。 它们把 DOM、事件、Ajax 这些脏活做顺了，

https://jianghu.zturn.top/series/framework-jianghu/framework-jianghu-03-react-rewrote-ui-around-state-and-rendering.html 2026-04-12T09:35:45.402Z 2026-04-12T09:35:45.402Z

框架江湖（三）：React 赢的不是一个库位，而是重写了 UI 的思考方式 01｜React 真正切进来的，不是一个“框架空位”，而是一套旧心智的疲劳 前一篇讲到， Backbone、Knockout、Ember、AngularJS 都在认真回答同一个问题： 浏览器应用到底该怎样

https://jianghu.zturn.top/series/framework-jianghu/framework-jianghu-04-vue-won-by-lowering-adoption-governance-cost.html 2026-04-12T09:35:45.403Z 2026-04-12T09:35:45.403Z

框架江湖（四）：Vue 的突围不只是语法友好，而是把框架采纳成本和治理摩擦压低了 01｜如果说 React 改写了 UI 心智，那 Vue 改写的就是采纳路径 讲完 React 以后， 很容易出现一种过于顺滑的历史想象： 既然 React 重写了 UI 思考方式， 那后面的主流框

https://jianghu.zturn.top/series/framework-jianghu/framework-jianghu-05-svelte-and-signals-reopened-the-runtime-war.html 2026-04-12T09:35:45.404Z 2026-04-12T09:35:45.404Z

框架江湖（五）：Svelte、Signals 不是新奇语法，而是对 React 时代运行时重量的一次反攻 01｜React 赢得越彻底，它留下来的默认重量就越容易被重新审问 前两篇讲的是框架为什么会出现， 前一篇讲的是 React 和 Vue 怎样分别拿到主流秩序位置。 可历史到

https://jianghu.zturn.top/series/framework-jianghu/framework-jianghu-06-frameworks-became-the-default-governance-layer.html 2026-04-12T09:35:45.404Z 2026-04-12T09:35:45.404Z

框架江湖（六）：框架为什么从可选 UI 工具，长成了现代前端默认的治理层 01｜写到今天，最值得追问的已经不是“选哪个框架”，而是“为什么必须先选框架” 前面五篇一路讲下来， 我们已经看到几轮很明显的秩序变化： jQuery 把浏览器现实先做顺 Backbone、Knockout

https://jianghu.zturn.top/series/frontend-engineering-jianghu/frontend-engineering-jianghu-00-intro.html 2026-04-12T09:35:45.405Z 2026-04-12T09:35:45.405Z

前端工程化江湖：前端不是天然复杂，而是在网页应用化之后，被一步步逼成了一整套工程机器 今天很多人一提到前端工程化，第一反应往往都差不多： 配置很重 工具很多 构建链很长 dev server、热更新、lint、测试、打包、部署全都绕不开 于是很容易得出一种结论： 前端天生就是复杂

https://jianghu.zturn.top/series/frontend-engineering-jianghu/frontend-engineering-jianghu-01-front-end-was-not-born-engineered-it-was-forced-by-scale-and-performance.html 2026-04-12T09:35:45.411Z 2026-04-12T09:35:45.411Z

前端工程化江湖（一）：前端最早并不是工程化出来的，它只是慢慢被规模和性能逼出构建需求 01｜前端工程化最早不是“大家突然爱上了复杂工具”，而是前端这件事本身先变了 今天很多人一说起前端工程化，第一反应往往是： 配置太多 工具太重 构建太慢 学习成本太高 于是很容易顺着得出一个结论

https://jianghu.zturn.top/series/frontend-engineering-jianghu/frontend-engineering-jianghu-02-grunt-and-gulp-turned-dirty-work-into-pipelines.html 2026-04-12T09:35:45.412Z 2026-04-12T09:35:45.412Z

前端工程化江湖（二）：Grunt / Gulp 为什么会先火，因为前端第一次把脏活累活正式做成了流水线 01｜如果说第一篇讲的是“前端为什么开始需要构建”，那第二篇要讲的就是：谁先把这件事做成了制度 第一篇讲到最后，其实已经把一个历史门槛立住了： 前端还没有成熟工程体系，但已经不

https://jianghu.zturn.top/series/frontend-engineering-jianghu/frontend-engineering-jianghu-03-webpack-became-king-by-understanding-the-whole-app.html 2026-04-12T09:35:45.413Z 2026-04-12T09:35:45.413Z

前端工程化江湖（三）：webpack 为什么会一度成王，因为前端很快发现，光把步骤串起来还不够，你还得真正理解整个应用 01｜如果说第二篇讲的是“前端第一次把脏活做成流水线”，那第三篇要讲的就是：为什么流水线很快也不够了 第二篇讲到最后，其实已经留下了一个非常关键的悬念。 Gru

https://jianghu.zturn.top/series/frontend-engineering-jianghu/frontend-engineering-jianghu-04-babel-bound-future-javascript-to-todays-workflow.html 2026-04-12T09:35:45.413Z 2026-04-12T09:35:45.413Z

前端工程化江湖（四）：Babel 为什么会和 bundler 绑成现代前端基建，因为前端接下来要解决的，已经不只是怎么装配应用，还包括怎么把未来语法提前带到今天 01｜如果说第三篇讲的是“谁来替应用做总装配”，那第四篇要讲的就是：谁来替未来语法先垫进今天 写到第三篇，其实前端工程

https://jianghu.zturn.top/series/frontend-engineering-jianghu/frontend-engineering-jianghu-05-rollup-snowpack-vite-were-the-counterattack.html 2026-04-12T09:35:45.413Z 2026-04-12T09:35:45.413Z

前端工程化江湖（五）：Rollup / Snowpack / Vite 为什么会代表反攻，因为前端很快又会反问：这套越来越重的工程机器，自己是不是也该被重新改造了 01｜如果说前四篇讲的是前端工程机器怎么一步步长大，那最后一篇要讲的就是：它为什么很快又开始被反过来怀疑 写到第四篇

https://jianghu.zturn.top/series/html-jianghu/html-jianghu-00-intro.html 2026-04-12T09:35:45.414Z 2026-04-12T09:35:45.414Z

HTML 江湖：网页骨架不是长出来的，是一路妥协出来的 今天所有前端都在写 HTML。 可很少有人会先问一句： 为什么浏览器要对那么多根本不该工作的页面继续负责？ 为什么 Web 世界宁愿把错误处理写进标准，也不肯像 XML 那样，遇到错误就干脆判死？ 为什么很多人一边嫌 HTM

https://jianghu.zturn.top/series/html-jianghu/html-jianghu-01-who-defines-web-pages.html 2026-04-12T09:35:45.414Z 2026-04-12T09:35:45.414Z

HTML 江湖（一）：谁有权定义网页长什么样？ 01｜这门语言最早的现场，不像前端课，更像 CERN 的文档室 如果你今天去看 1992 年那页著名的 MarkUp 文档，第一眼甚至会有点失望。 没有组件。 没有布局体系。 没有“如何做出更酷网页”的野心。 它不像前端圣经。 更像

https://jianghu.zturn.top/series/html-jianghu/html-jianghu-02-before-html-stabilized-browser-war.html 2026-04-12T09:35:45.415Z 2026-04-12T09:35:45.415Z

HTML 江湖（二）：标准还没站稳，浏览器已经先往 HTML 里塞私货 01｜这场仗最早的开火方式，不是规范会议，而是浏览器厂商往 HTML 里偷偷塞礼物 如果你把 HTML 的历史只想成“标签慢慢变多”，那第二篇会显得像一堆旧标签回忆录。 它其实不是。 它更像一场地盘战。 第二

https://jianghu.zturn.top/series/html-jianghu/html-jianghu-03-why-w3c-wanted-xml.html 2026-04-12T09:35:45.415Z 2026-04-12T09:35:45.415Z

HTML 江湖（三）：W3C 为什么想把 Web 带回 XML 01｜如果你只记得 XHTML 很严，那你会错过它最迷人的地方 今天再提 XHTML，很多前端的第一反应都差不多： 教条 形式主义 过时 一条最后没走通的老路 从结果上看，这些标签不算冤。 可如果你只记住结果，你就会

https://jianghu.zturn.top/series/html-jianghu/html-jianghu-04-how-whatwg-became-mainstream.html 2026-04-12T09:35:45.416Z 2026-04-12T09:35:45.416Z

HTML 江湖（四）：WHATWG 是怎么从边缘阵营变成主线的 01｜WHATWG 最像的一幕，不是建站，而是有人先把桌子掀了一角 如果你只看后来的结果，会觉得 WHATWG 很像一条自然长出来的主线。 可在 2004 年，它一点都不像主线。 它更像一群浏览器实现者对着官方流程说

https://jianghu.zturn.top/series/html-jianghu/html-jianghu-05-why-html5-was-amnesty.html 2026-04-12T09:35:45.416Z 2026-04-12T09:35:45.416Z

HTML 江湖（五）：HTML5 为什么不是一次升级，而是一次招安 01｜HTML5 最像的，不是新版本发布，而是朝廷终于决定招安山头 很多人第一次听到 HTML5，记住的是这些名字： video audio canvas header section 这当然没错。 但如果你把

https://jianghu.zturn.top/series/html-jianghu/html-jianghu-06-who-defines-html-now.html 2026-04-12T09:35:45.417Z 2026-04-12T09:35:45.417Z

HTML 江湖（六）：Living Standard 之后，到底谁在定义 HTML 01｜这一篇真正要讲的，不是文档格式，而是一场权力收口 有一段时间，Web 开发圈特别喜欢问一个问题： HTML5 到底什么时候算“写完”？ 第六篇要收的，不是一个技术名词。 而是一场正统之争的尾

https://jianghu.zturn.top/series/html-jianghu/html-jianghu-07-why-html-chose-not-breaking.html 2026-04-12T09:35:45.417Z 2026-04-12T09:35:45.417Z

HTML 江湖（七）：HTML 为什么最终没有追求完美，而是追求不坏 01｜这一篇最好的开场，不是抽象原则，而是一张本该报废却还在工作的坏页面 前端圈经常会有一种情绪。 一遇到奇怪兼容性、宽容解析、历史包袱，就忍不住想说： 浏览器为什么不能更严格一点？ 这个愿望很正常。 谁不想面

https://jianghu.zturn.top/series/javascript-jianghu/javascript-jianghu-00-intro.html 2026-04-12T09:35:45.418Z 2026-04-12T09:35:45.418Z

JavaScript 江湖：这门语言不是设计出来的，是被时代硬推出来的 今天几乎所有前端都在写 JavaScript。 可很少有人会先问一句： 为什么一门据说只花了十天写出来的语言，最后会变成整个 Web 平台最难绕开的底座？ 为什么它一开始像浏览器里的一点小把戏，后来却一路扩张

https://jianghu.zturn.top/series/javascript-jianghu/javascript-jianghu-01-ten-days-language-became-web-foundation.html 2026-04-12T09:35:45.419Z 2026-04-12T09:35:45.419Z

JavaScript 江湖（一）：十天写出来的语言，为什么最后活成了整个 Web 的底座 01｜JavaScript 最有名的出身，不是优雅，是仓促 如果一门语言的出身要靠一句话传世，那 JavaScript 大概已经赢了。 那句话就是： 十天写出来。 这句太有戏。 它短，狠，带

https://jianghu.zturn.top/series/javascript-jianghu/javascript-jianghu-02-browser-war-split-javascript.html 2026-04-12T09:35:45.421Z 2026-04-12T09:35:45.421Z

JavaScript 江湖（二）：标准还没定，浏览器大战已经把它打成两门话 01｜这一回，敌人不是语法怪，而是分裂 第一篇里，JavaScript 还像个仓促上场的新兵。 它带着明显的时间压力和市场痕迹，被 Netscape 赶着塞进浏览器，先去接住“网页能不能动起来”这件事。

https://jianghu.zturn.top/series/javascript-jianghu/javascript-jianghu-03-ecmascript-was-a-truce.html 2026-04-12T09:35:45.421Z 2026-04-12T09:35:45.421Z

JavaScript 江湖（三）：ECMAScript 不是加冕礼，更像浏览器大战中的停火协议 01｜很多人以为标准化是加冕，其实 JavaScript 更像先被送去急诊 如果你只从今天往回看，很容易把 ECMAScript 理解成一场顺理成章的加冕。 前面有语言诞生。 中间有浏

https://jianghu.zturn.top/series/javascript-jianghu/javascript-jianghu-04-why-es4-collapsed.html 2026-04-12T09:35:45.422Z 2026-04-12T09:35:45.422Z

JavaScript 江湖（四）：一门语言差点把自己重写过头，ES4 为什么最后夭折 01｜这场事故最可怕的地方，不是提案太大，而是整门语言差点在现代化时把自己谈崩 前面第三篇讲到 ECMAScript 更像停火协议。 它先把语言核心拉回一张桌子，至少让 JavaScript 不

https://jianghu.zturn.top/series/javascript-jianghu/javascript-jianghu-05-after-ajax-javascript-became-engine.html 2026-04-12T09:35:45.423Z 2026-04-12T09:35:45.423Z

JavaScript 江湖（五）：Ajax 之后，JavaScript 从页面补丁变成了应用引擎 01｜这一次真正变的，不是语法，而是网页对“像应用一样工作”的野心 前面四篇一路讲下来，主线大体还都停在“语言自身如何活下来”。 第一篇讲仓促出生。 第二篇讲浏览器大战里的分裂。 第

https://jianghu.zturn.top/series/javascript-jianghu/javascript-jianghu-06-v8-jit-changed-javascript.html 2026-04-12T09:35:45.423Z 2026-04-12T09:35:45.423Z

JavaScript 江湖（六）：V8、JIT 和 Chrome，为什么让 JavaScript 从能用变成必须认真对待 01｜这场仗表面在比快，底下其实在争：浏览器到底要不要认真把 JavaScript 当核心资产 第五篇讲到 Ajax 之后，Web 开始想更像应用。 页面不再

https://jianghu.zturn.top/series/javascript-jianghu/javascript-jianghu-07-nodejs-moved-javascript-power-center.html 2026-04-12T09:35:45.424Z 2026-04-12T09:35:45.424Z

JavaScript 江湖（七）：Node.js 不是换个运行时，它把 JavaScript 送进了新的权力中心 01｜这一步真正惊人的，不是“JS 也能写后端”，而是它终于不必再看浏览器脸色 第六篇讲到，性能战争把 JavaScript 从“能用的网页脚本”正式扶正成了“必须认

https://jianghu.zturn.top/series/javascript-jianghu/javascript-jianghu-08-es6-made-javascript-modern.html 2026-04-12T09:35:45.428Z 2026-04-12T09:35:45.428Z

JavaScript 江湖（八）：JavaScript 真正长成现代模样，不是在 1995，而是在 ES6 01｜这篇真正要讲的，不是 ES6 功能清单，而是“现代 JavaScript”为什么终于像一件真的东西了 写到第八篇，主线其实已经走到一个很关键的位置。 第一篇讲的是它如

https://jianghu.zturn.top/series/modularization-jianghu/modularization-jianghu-00-intro.html 2026-04-12T09:35:45.428Z 2026-04-12T09:35:45.428Z

模块化江湖：一个简单的 import，背后其实是十几年互不服气的组织方式战争 今天的前端、Node 项目，几乎都会写 import。 很多时候，我们甚至已经不太把它当回事。 可如果你退一步看，会发现这件事其实非常奇怪： 为什么一门今天连“引入另一个文件”都看起来理所当然的语言，曾

https://jianghu.zturn.top/series/modularization-jianghu/modularization-jianghu-01-before-modules-everything-leaked-to-global.html 2026-04-12T09:35:45.429Z 2026-04-12T09:35:45.429Z

模块化江湖（一）：在模块出现之前，JavaScript 不是不会组织代码，而是只能靠全局变量和加载顺序硬撑 01｜模块化问题最早不是“优雅不优雅”，而是代码开始真的互相踩了 今天如果你跟一个前端说“这个项目完全没有模块系统”，他大概率会先皱眉。 因为在现代开发者的直觉里，这几乎已

https://jianghu.zturn.top/series/modularization-jianghu/modularization-jianghu-02-commonjs-first-won-in-node.html 2026-04-12T09:35:45.433Z 2026-04-12T09:35:45.433Z

模块化江湖（二）：真正先把模块化制度化的，不是浏览器，而是 Node 世界里的 CommonJS 01｜如果说第一篇讲的是“旧办法为什么撑不住了”，那第二篇要讲的就是：第一套真制度为什么先长在 Node 里 第一篇讲到，JavaScript 在没有正式模块制度的时候，并不是完全不

https://jianghu.zturn.top/series/modularization-jianghu/modularization-jianghu-03-amd-grew-out-of-browser-reality.html 2026-04-12T09:35:45.433Z 2026-04-12T09:35:45.433Z

模块化江湖（三）：AMD 不是社区故意分裂，它是浏览器现实对 Node 式模块制度的一次反击 01｜如果说第二篇讲的是“Node 世界终于有了秩序”，那第三篇要讲的就是：为什么浏览器没有乖乖照抄 第二篇讲到，CommonJS 最早先在 Node.js 里把模块化做成了真正可执行的

https://jianghu.zturn.top/series/modularization-jianghu/modularization-jianghu-04-bundlers-became-temporary-constitution.html 2026-04-12T09:35:45.433Z 2026-04-12T09:35:45.433Z

模块化江湖（四）：当谁都没法统一全场时，bundler 就成了那部临时宪法 01｜如果说前三篇讲的是“制度为什么分裂”，那第四篇要讲的就是：分裂之后到底谁来维持秩序 写到这里，模块化江湖其实已经出现了一个非常典型的 JavaScript 式局面。 第一篇讲的是，旧时代靠全局变量、

https://jianghu.zturn.top/series/modularization-jianghu/modularization-jianghu-05-es-modules-won-but-war-didnt-end.html 2026-04-12T09:35:45.434Z 2026-04-12T09:35:45.434Z

模块化江湖（五）：ES Modules 赢了，但它赢下的是标准地位，不是一夜之间消灭所有旧世界 01｜如果说前四篇讲的是“模块制度怎么一路分裂、补位、协调”，那最后一篇要讲的就是：为什么标准终于来了，战争却没有立刻结束 写到第五篇，模块化江湖已经走过了很长一段弯路。 第一篇讲的是

https://jianghu.zturn.top/series/npm-jianghu/npm-jianghu-00-how-install-became-infrastructure.html 2026-04-12T09:35:45.434Z 2026-04-12T09:35:45.434Z

npm 江湖：装包这件小事，怎么长成了前端基础设施 今天很多前端、Node 项目一打开，几乎都会看到： package.json node modules npm install 一长串直接依赖和间接依赖 很多时候，我们甚至已经不太把这件事当回事。 可如果你退一步看，就会发现这件

https://jianghu.zturn.top/series/npm-jianghu/npm-jianghu-01-why-javascript-needed-central-registry-after-node.html 2026-04-12T09:35:45.434Z 2026-04-12T09:35:45.434Z

npm 江湖（一）：Node 出现后，JavaScript 为什么突然需要中央仓库 01｜这篇真正要先立住的，不是“npm 很方便”，而是 JavaScript 世界第一次突然急需一个默认的代码流通入口 今天我们一说到 npm，第一反应通常是： 装依赖 发包 跑脚本 看 pack

https://jianghu.zturn.top/series/npm-jianghu/npm-jianghu-02-why-npm-loved-tiny-packages.html 2026-04-12T09:35:45.435Z 2026-04-12T09:35:45.435Z

npm 江湖（二）：为什么 npm 世界总爱把东西越拆越小 01｜这篇真正要讲的，不是“JavaScript 社区为什么爱造轮子”，而是 npm 为什么会把“拆得更细”推成一种看起来很合理的生态直觉 今天很多人回头吐槽 npm 生态，最常见的一类抱怨就是： 一个项目依赖太多 一个

https://jianghu.zturn.top/series/npm-jianghu/npm-jianghu-03-left-pad-and-public-roads.html 2026-04-12T09:35:45.435Z 2026-04-12T09:35:45.435Z

npm 江湖（三）：left-pad 一夜惊魂，谁才拥有公共道路 01｜这篇真正要先立住的，不是“11 行代码也能害惨世界”，而是整个行业第一次被迫承认自己已经活在一套高度互相依赖的公共基础设施里 今天大家一提到 left-pad，最容易记住的表层梗通常是： 一个只有十来行的小包

https://jianghu.zturn.top/series/npm-jianghu/npm-jianghu-04-why-semver-kept-failing.html 2026-04-12T09:35:45.437Z 2026-04-12T09:35:45.437Z

npm 江湖（四）：semver 人人都懂，为什么现实还是照样翻车 01｜这篇真正要先立住的，不是“semver 不靠谱”，而是 npm 生态为什么必须先相信它 经历过 left-pad 之后， 大家很容易顺着往下得出一个更悲观的结论： 依赖链太深 维护者不一定稳定 平台也会改规

https://jianghu.zturn.top/series/npm-jianghu/npm-jianghu-05-why-yarn-and-pnpm-emerged.html 2026-04-12T09:35:45.438Z 2026-04-12T09:35:45.438Z

npm 江湖（五）：npm 都赢了，Yarn 和 pnpm 为什么还会杀出来 01｜这篇真正要先立住的，不是“后来大家有了更多包管理器”，而是 npm 赢下中央入口之后，真正被集中抱怨的已经不再是入口，而是入口后面的安装现实 到这一步， npm 的中央地位其实已经很难动摇了。 大

https://jianghu.zturn.top/series/npm-jianghu/npm-jianghu-06-where-package-trust-comes-from.html 2026-04-12T09:35:45.438Z 2026-04-12T09:35:45.438Z

npm 江湖（六）：包是装上了，信任到底从哪来 01｜这篇真正要先立住的，不是“npm 现在更重视安全了”，而是为什么安全问题最后会自然升级成供应链问题 如果你把 npm 江湖 前面几篇连起来看， 会发现这条线其实一直在往一个越来越重的方向推： 第一篇讲中央入口形成 第二篇讲小包

https://jianghu.zturn.top/series/open-source-jianghu/open-source-jianghu-00-intro.html 2026-04-15T02:32:34.258Z 2026-04-15T02:32:34.258Z

开源江湖：开源史首先是规则史，不是「让世界更美好」的道德史 今天很多项目一打开，几乎都会看到： 根目录的 LICENSE README 里一句「欢迎贡献」 CONTRIBUTING 与 Issue 模板 CI 跑在公开的流水线里 依赖树指向成千上万个名字陌生的包 我们很容易把这一

https://jianghu.zturn.top/series/open-source-jianghu/open-source-jianghu-01-gnu-and-free-software-ethics.html 2026-04-14T06:19:32.665Z 2026-04-14T06:19:32.665Z

开源江湖（一）：没有「四项自由」，后面的许可证战争都会飘在半空 很多后来的争论——GPL 是不是太「硬」、MIT 是不是太「软」、企业是不是在「白嫖」——听起来像在争 人品 。 可如果你回到自由软件运动真正要解决的问题，会发现它最初争的并不是人品，而是一种更朴素、也更刺痛的恐惧：

https://jianghu.zturn.top/series/open-source-jianghu/open-source-jianghu-02-gpl-and-copyleft.html 2026-04-14T06:19:39.062Z 2026-04-14T06:19:39.062Z

开源江湖（二）：GPL 把「你可以用」写成了「带条件的可以」 上一篇把「自由」落到了用户主权：运行、研究、修改、再分发。 本篇要处理一个更冷、更硬的问题： 当软件可以被无限复制，善意靠什么变成可执行的共同体纪律？ GNU 通用公共许可证（GPL）给出的答案，是版权法里很反直觉的一

https://jianghu.zturn.top/series/open-source-jianghu/open-source-jianghu-03-linux-kernel-governance.html 2026-04-14T06:19:45.422Z 2026-04-14T06:19:45.422Z

开源江湖（三）：内核最难的不是第一行代码，而是谁有权说「进」 许可证解决的是「 分发出去之后，接收者还有什么权利 」。 但在此之前，还有一个更日常、也更刺的问题： 这个补丁，到底进不进主分支？谁说了算？凭什么？ Linux 内核共同体几十年来的演化，几乎是开源世界最硬的「治理样本

https://jianghu.zturn.top/series/open-source-jianghu/open-source-jianghu-04-osi-and-open-source-narrative.html 2026-04-14T06:19:55.780Z 2026-04-14T06:19:55.780Z

开源江湖（四）：Open Source 很大程度上是一次「品牌与定义权」重启 1998 年前后，英语世界里发生了一件看起来很「公关」、但后果很深的事： 一群人开始更积极地使用 「Open Source」 这个词，并围绕它组织定义、游说与产业对话。 在 GNU / FSF 的叙事里

https://jianghu.zturn.top/series/open-source-jianghu/open-source-jianghu-05-company-and-community.html 2026-04-14T06:19:56.289Z 2026-04-14T06:19:56.289Z

开源江湖（五）：企业不是开源的「对立面」，常常是把它推成工业默认的力量 有一种流行叙事把开源描写成「纯洁社区 vs 邪恶公司」。 它好用，但常常失真。 更贴近制度史的说法是： 公司进入开源之后，权力从「志愿声誉」与「合并门文化」旁边，又长出一套「工时、路线图与合规」的硬杠杆 ——

https://jianghu.zturn.top/series/open-source-jianghu/open-source-jianghu-06-gpl-enforcement-busybox-sco.html 2026-04-14T06:20:02.691Z 2026-04-14T06:20:02.691Z

开源江湖（六）：当邮件列表说不通，诉状会把哲学翻译成可签字的风险 开源共同体最温柔的想象是： 大家讲道理就行。 但制度史里还有另一面：当分歧涉及 是否遵守许可证义务 、是否愿意在发现违规后纠正，讨论会从邮件列表滑向律师函、禁令申请、和解条款与「以后不许再犯」的承诺—— 法律语言

https://jianghu.zturn.top/series/open-source-jianghu/open-source-jianghu-07-open-source-legacies-and-anxieties.html 2026-04-14T06:23:53.108Z 2026-04-14T06:23:53.108Z

开源江湖（七）：开源赢了默认，但默认不是免维护 如果把这条系列线从 1980 年代拉到此刻，你会看到一种看似矛盾的局面： 默认更开放了 ：公开仓库、CI、复用依赖、上游优先，几乎成了行业常识。 默认也更焦虑了 ：供应链攻击、维护者倦怠、许可证扫描、地缘政治风险，一样成了常识。 这

https://jianghu.zturn.top/series/operating-system-jianghu/operating-system-jianghu-00-intro.html 2026-04-24T02:13:33.003Z 2026-04-24T02:13:33.003Z

操作系统江湖：操作系统史首先是谁定义接口默认与复制权的历史，不只是内核换代史 今天很多开发者一开机房话题，嘴上说的是： 哪个发行版「稳」 容器里是 alpine 还是 ubuntu systemd 爱不爱 WSL 算不算「真 Linux」 云上选 ARM 还是 x86 我们很容易

https://jianghu.zturn.top/series/operating-system-jianghu/operating-system-jianghu-01-unix-started-as-copyable-tradition.html 2026-04-24T02:13:33.003Z 2026-04-24T02:13:33.003Z

操作系统江湖（一）：Unix 先是能被人拷走的传统，才变成合同里的产品 上一篇操作系统江湖：操作系统史首先是谁定义接口默认与复制权的历史，不只是内核换代史先把总问题立住了：操作系统从来不是透明底层，而是一层 接口默认 + 分发授权 叠出来的政治。 所以第一篇不能急着讲 Linux

https://jianghu.zturn.top/series/typescript-jianghu/typescript-jianghu-00-intro.html 2026-04-12T09:35:45.439Z 2026-04-12T09:35:45.439Z

TypeScript 江湖：一个并非 JavaScript 官方的类型系统，最后却变成了现代前端几乎默认接受的语言秩序 今天你去看一个稍微正式一点的前端项目，十有八九都会看到： tsconfig.json .ts / .tsx 编辑器里的类型提示 构建链、测试链、脚手架默认带着

https://jianghu.zturn.top/series/typescript-jianghu/typescript-jianghu-01-javascript-long-resisted-types-because-its-identity-valued-flexibility.html 2026-04-12T09:35:45.440Z 2026-04-12T09:35:45.440Z

TypeScript 江湖（一）：JavaScript 社区为什么长期本能地排斥类型，因为这门语言最初的自我认同，本来就站在灵活和低门槛那一边 01｜今天很多人觉得 TypeScript 很自然，可在很长一段时间里，“给 JavaScript 加类型”这句话听起来其实非常不对劲

https://jianghu.zturn.top/series/typescript-jianghu/typescript-jianghu-02-typescript-won-by-gradual-adoption-not-revolution.html 2026-04-12T09:35:45.441Z 2026-04-12T09:35:45.441Z

TypeScript 江湖（二）：TypeScript 为什么能切进来，不是因为它更正统，而是因为它从第一天起就选择了渐进收编，而不是正面革命 01｜如果第一篇讲的是 JavaScript 世界为什么会本能地先皱眉，那第二篇要回答的就是：TypeScript 为什么没有死在这道皱

https://jianghu.zturn.top/series/typescript-jianghu/typescript-jianghu-03-flow-was-strong-but-lost-the-ecosystem-war.html 2026-04-12T09:35:45.442Z 2026-04-12T09:35:45.442Z

TypeScript 江湖（三）：Flow 为什么一度强，后来却没吃下天下，因为类型之争最后拼的不只是理论，还拼生态和默认入口 01｜如果第二篇讲的是 TypeScript 为什么能进场，那第三篇要回答的就是：为什么当年看起来同样很能打的 Flow，最后却没有把这场仗打成自己的

https://jianghu.zturn.top/series/typescript-jianghu/typescript-jianghu-04-tsserver-made-editor-experience-the-real-battlefield.html 2026-04-12T09:35:45.442Z 2026-04-12T09:35:45.442Z

TypeScript 江湖（四）：tsserver 为什么会构成决定性优势，因为开发者最后投票投的，往往不是理论，而是每天写代码时的体感 01｜如果前三篇讲的是为什么需要秩序、谁更会进场、谁在生态入口之争里掉队，那第四篇要讲的就是：真正决定大多数人站队的，很多时候根本不是类型理论

https://jianghu.zturn.top/series/typescript-jianghu/typescript-jianghu-05-typescript-became-default-because-it-minimized-governance-friction.html 2026-04-12T09:35:45.442Z 2026-04-12T09:35:45.442Z

TypeScript 江湖（五）：TypeScript 为什么最后从可选变默认，因为它逐渐不再只是类型系统，而成了现代前端最低摩擦的治理方案 01｜如果前四篇讲的是它为什么能进来、为什么竞争者掉队、为什么编辑器体验会构成决定性优势，那最后一篇要讲的就是：TypeScript 为什

https://jianghu.zturn.top/topic/javascript/JavaScript 二进制数据七十二变：从 ArrayBuffer 到 Blob 的奇幻漂流.html 2026-04-12T09:35:45.442Z 2026-04-12T09:35:45.442Z

JavaScript 二进制数据七十二变：从 ArrayBuffer 到 Blob 的奇幻漂流 一份 JavaScript 中“二进制生态”极简内功心法 诙谐版 · 但保证概念不缩水 --- 前言：为什么我们要跟二进制“死磕”？ 前端的世界看似是字符串、JSON 和 DOM 的乐