个人笔记

各类学习笔记与记录。

目录

• 国际象棋
• 文化
• 游戏
• 政治
• SIM 卡

Tags

Tag: Android

• 手机作为 IPv6服务器

Tag: IPv6

• 手机作为 IPv6服务器

Tag: 手机

• 手机作为 IPv6服务器

Tag: 服务器

• 手机作为 IPv6服务器

Tag: 网络

• 手机作为 IPv6服务器

README

国际象棋

国际象棋战术、开局、残局等学习笔记。

国际象棋战术

一、基础战术（入门必学）

1. 捉双（Fork）

定义：一子同时攻击对方两个或更多目标，对方无法兼顾。

典型类型：

• 马捉双：最常见，因马的跳跃特性易同时攻击高低线路
• 后捉双：威力最大，但通常价值过高，需谨慎
• 象/车捉双：多见于开放线路

示例：马跳到 d5，同时攻击对方在后线的后和在前线的车。

2. 牵制（Pin）

定义：利用长兵器（后、车、象）攻击对方某子，使其因保护更重要棋子（通常是王或后）而无法移动。

类型：

• 绝对牵制：被牵制子保护的是王，移动即违例
• 相对牵制：保护的是后或车等重要子力

战术要点：被牵制的子力暂时失去活动能力，可趁机攻击或围困。

3. 串击（Skewer）

定义：与牵制相反，长兵器先攻击价值高的棋子，对方躲避后，后面的低价值棋子被吃。

常见形式：车或后沿横线/直线串击王与后的排列。

二、中级战术（需计算配合）

4. 闪击（Discovery Attack）

定义：移动一子，露出后方远程兵器的攻击线路，形成双重威胁。

威力等级：

• 普通闪击：露出后的攻击
• 闪将：露出的攻击是将军，强制对方应着
• 双将：闪击同时本身也将军，极其致命

5. 消除保护（Removing the Defender）

定义：通过兑换或逼迫等手段，消灭对方关键子的保护者，使其暴露。

常见手法：

• 吃掉保护子
• 引开保护子（见下文引离）
• 逼迫保护子承担其他防守任务

6. 引离（Deflection）

定义：逼迫对方棋子离开关键格子或线路，破坏其防御体系。

应用场景：

• 引开保护王的棋子
• 迫使对方车离开底线
• 让开关键线路供己方使用

7. 堵塞（Blocking/Interference）

定义：在对方棋子之间插入一子，切断其联系或阻挡其线路。

典型情况：

• 用兵或轻子塞入对方双车之间
• 阻挡象的斜线
• 切断后对远处棋子的保护

三、高级战术（组合运用）

8. 过载（Overloading）

定义：对方某一子承担过多防守任务，无法同时兼顾。

利用方式：制造两个同时需要该子防守的威胁，使其顾此失彼。

9. 兵升变（Promotion）

定义：兵冲到对方底线升变为后或其他棋子，瞬间改变力量对比。

战术配合：

• 升变威胁：迫使对方弃子阻止
• 引离升变：用兵吸引对方重子，制造其他突破

10. 困杀（Smothered Mate）

定义：马单独将杀被对方自己的子力包围的王，典型特征是王无法移动且被己方棋子堵住逃生格。

经典模式：马在 f2/f7 或 g4/g5 等格，王被自己的兵和子包围在角落。

四、战术识别与训练建议

战术信号（何时寻找战术机会）：

1. 对方王暴露或子力位置不协调
2. 底线薄弱（无车防守）
3. 子力拥挤（易堵塞、牵制）
4. 后、车、象位于同一直线（易串击）

训练方法：

• 谜题训练：每日解 5-10 道战术题（推荐 Chess.com、Lichess 的战术训练）
• 模式识别：重点练习每种战术的典型几何图形
• 强制变着计算：养成“对方必须应着“的思维习惯

经典战术组合示例：

引离 + 闪击：用后 sacrifice 引开对方防守马，露出己方象的将军，同时后车配合杀王。

掌握这些战术需要计算力与模式识别的结合。建议从捉双、牵制等简单战术入手，逐步过渡到多步战术组合。

文化

传统文化、命理学等杂学笔记。

五行纳音命详解

五行纳音命是中国传统命理学中一个极具特色的理论体系，通过将天干地支组合与古代音律相结合，形成六十种独特的五行属性（称为“纳音五行“），用于分析人的性格、命运和运势走向。

一、基本概念

1. 什么是纳音五行？

• 正五行：天干地支本身固有的五行属性（如甲乙属木，丙丁属火）
• 纳音五行：天干地支两两组合后产生的新五行属性，又称“假借五行“，因借用古代五音（宫、商、角、徵、羽）与十二音律配合而得名

2. 核心理论 纳音五行源自先天八卦，通过数理组合推算。例如：

• 甲子、乙丑 → 海中金
• 丙寅、丁卯 → 炉中火
• 2025乙巳年 → 覆灯火（也称佛灯火）

二、六十甲子纳音五行表

每两个干支组合对应一种纳音五行，形成完整的60组循环：

三、命理应用维度

1. 性格特质分析 同类正五行因纳音不同而差异显著：

• 金命对比：海中金（低调隐忍）、白蜡金（外强中干）、钗钏金（重外表修饰）
• 火命对比：覆灯火（温和慈悲但易优柔寡断）、霹雳火（果敢但易冲动）

2. 运势吉凶预测 纳音五行可捕捉正五行难以体现的微妙变化：

• 顺运：年柱“沙中金“遇大运“长流水“，主贵人引动资源流动（投资获利、跨界合作）
• 逆运：日柱“炉中火“遇流年“大海水“，水火相激，需防突发健康或情感冲突

3. 婚姻配对法则 通过“气场共振“分析，与生肖、日主形成三维校验：

• 上等婚：男“城墙土“配女“杨柳木“（木扎根于土，夫妻互助成长）
• 冲突预警：男“山下火“配女“天河水“，火被水压，易现女方强势压制

4. 六亲关系解读

• 年柱纳音：代表祖荫基因
• 月柱纳音：父母宫能量
• 时柱纳音：子女宫信息 例：年柱“覆灯火“被月柱“大林木“所耗（木生火但灯火遇旺木反成“风吹火灭“），主父母缘薄或关系疏离

四、2025年实例分析

2025乙巳年 → 覆灯火命

• 性格：内心温暖、富有同情心，但易优柔寡断、犹豫不决
• 事业：创造力强，善于抓住机遇，但需防过度热情导致盲目冒进
• 特征：如夜晚灯火，光芒柔和不刺眼，给人温暖感，团队中的和谐因子

五、重要原则与局限

使用要点：

1. 辅助地位：不可反客为主取代正五行分析
2. 时空衰减：现代影响力弱于古代（如“沙中金“古代指矿藏，现代可引申为互联网数据）
3. 位置关键：纳音生克需结合干支位置，隔柱效力锐减
4. 类象理解：需结合现实物理特性（如“天上火“不克“海中金“，反主远距离贵人）

与正五行的关系： 两者形成“显隐双轨“判断体系——正五行揭示命局主干框架，纳音五行暗藏潜在特质与变数，互为补充印证

总结

五行纳音命是传统命理学的深化工具，通过六十甲子的精微划分，为命运分析提供了更丰富立体的维度。但需由专业人士结合完整八字（年月日时四柱）综合判断，不可仅凭年份纳音就断定一生吉凶。

Economics

Financial Markets (2011) with Robert Shiller

Financial Markets (2008) with Robert Shiller

散户大战华尔街

太燃了！散户vs华尔街世纪大战，一夜8次熔断，拔网线、禁止交易都用上了！

为什么马克思是错的？——全面批判马列主义的知名著作导读

各国即时支付方式

即时支付（Instant Payment / Fast Payment）是指款项通常在数秒内到达收款账户、资金立即可用，并且原则上全年无休运行的账户到账户支付。它和银行卡支付、电子钱包并不是同一层概念：

• 即时支付系统负责银行或支付机构之间的清算、结算与消息传递；
• 手机号、邮箱、二维码、虚拟支付地址是方便用户识别收款人的“别名”或入口；
• 银行 App、电子钱包和商户收银台则是面向用户的产品界面。

因此，印度用户常说“用 UPI”，巴西用户说“用 Pix”，实际上既可能是转账，也可能是扫码消费；而 Apple Pay、Google Pay 等主要是钱包或卡片载体，并不等于一个国家的即时支付基础设施。

亚洲

欧洲

美洲

加拿大的 Real-Time Rail（RTR）长期处于建设和调整阶段。在实际使用前，应查看 Payments Canada 的最新上线安排，不要把 Interac e-Transfer 与尚未全面投产的 RTR 混为一谈。

大洋洲

中东与非洲

跨境即时支付

即时支付网络大多首先服务本币境内交易，但跨境互联正在增加。例如：

• 新加坡 PayNow 已与泰国 PromptPay、印度 UPI 等网络建立连接；
• 东南亚多国央行正在推动二维码和即时支付互联；
• 欧洲的 SCT Inst 天然覆盖多个 SEPA 国家和地区，但只处理符合方案规则的欧元转账；
• 国际清算银行创新中心的 Nexus 等项目尝试用统一连接方式降低各国系统逐一对接的复杂度。

“几秒到账”不代表全球系统已经完全互通。跨境支付仍可能涉及换汇、额度、合规检查、参与银行范围和接收方费用。

使用时的风险

即时支付通常采用 push payment：付款人主动授权后，资金立即进入对方账户，往往难以撤回。付款前应：

1. 核对收款人姓名以及手机号、别名或账号；
2. 首次向陌生人或大额付款时先转一笔小额测试；
3. 不因“安全账户”“退款验证”或“屏幕共享指导”而转账；
4. 发现诈骗后立即联系付款机构，并保留交易编号和沟通记录；
5. 不把“银行能追踪”误解成“银行一定能追回”。

资料来源与继续查询

• 世界银行 Project FASTT：全球快速支付系统追踪器
• 国际清算银行：全球快速支付的区域比较
• 欧洲中央银行：什么是即时支付
• 欧洲中央银行：欧盟即时支付法规与实施时间表
• 美国联邦储备金融服务：FedNow 简介

各系统的额度、费用、覆盖银行和跨境连接会变化。实际付款前，应再查当地央行、系统运营方或开户机构的最新说明。

中国大陆：IBPS、支付宝与微信支付

网上支付跨行清算系统（IBPS）是银行间零售支付基础设施。用户通常通过银行 App 发起跨行转账。

支付宝和微信支付是商业钱包及支付平台，主要使用二维码、手机号或平台账户完成付款。它们覆盖面更广，但不等同于 IBPS。

IBPS 还与香港“转数快”连接，提供跨境支付通服务。

中国香港：FPS 转数快

转数快（FPS）连接银行及储值支付工具，支持港元和人民币即时转账。

用户可以使用手机号、邮箱、FPS ID 或二维码收付款。

FPS 还与中国内地 IBPS 连接，提供跨境支付通服务。

丹麦：MobilePay

MobilePay 是丹麦常用的移动支付服务，支持手机号转账、二维码及商户付款。

底层银行间快速支付由 Straksclearing 等基础设施支持。

加拿大：Interac e-Transfer 与 RTR

Interac e-Transfer 是加拿大目前广泛使用的个人和企业转账服务，通常通过邮箱或手机号通知及收款。

Real-Time Rail（RTR）是新的实时支付基础设施项目。其上线安排经历调整，不能把现有 Interac e-Transfer 与 RTR 混为一谈，使用前应查看 Payments Canada 的最新信息。

南非：PayShap

PayShap 面向低额即时支付，支持银行账号以及通常与手机号绑定的 ShapID。

南非还运行 Real-Time Clearing（RTC）等实时支付基础设施。

印度：UPI 与 IMPS

UPI 是印度的开放式即时支付接口，广泛用于个人转账、商户扫码、线上付款和自动扣款。常用标识包括 UPI ID、手机号和二维码。

IMPS 是较早推出的即时银行转账服务，也支持全年运行。

印度尼西亚：BI-FAST 与 QRIS

BI-FAST 是印度尼西亚央行建设的快速支付基础设施，支持银行账号和代理地址转账。

QRIS 是统一二维码标准，使不同银行和电子钱包能够在同一商户二维码上互操作。

哥伦比亚：Bre-B

Bre-B 是哥伦比亚央行推动的可互操作即时支付体系，使用手机号、证件号、邮箱或自定义别名收付款。

当地此前已有 Transfiya、Entre Cuentas 等快速转账服务，市场正在向更统一的互操作模式演进。

土耳其：FAST

FAST 是土耳其全天候运行的即时支付系统。

用户可以通过手机号、身份证号、邮箱等“便捷地址”代替银行账号，并可使用建立在 FAST 之上的二维码服务。

坦桑尼亚：TIPS

Tanzania Instant Payment System（TIPS）强调银行与移动货币运营商之间的互操作。

用户可通过银行或移动钱包入口，使用手机号等标识转账。

埃及：InstaPay

InstaPay 是埃及 Instant Payment Network 面向用户的主要入口。

它支持银行账号、手机号和即时支付地址转账，服务可全年使用。

墨西哥：SPEI、CoDi 与 DiMo

SPEI 是墨西哥的实时银行转账基础设施。

CoDi 在 SPEI 之上提供二维码及付款请求体验；DiMo 强化使用手机号收付款的体验。用户也可使用 CLABE 或银行卡号转账。

尼日利亚：NIBSS Instant Payment

NIBSS Instant Payment（NIP）是非洲较早实现大规模应用的即时支付网络之一。

用户可以通过银行 App、金融科技 App、USSD 或银行账号发起付款。

巴基斯坦：Raast

Raast 是巴基斯坦央行推动的即时支付系统，覆盖个人、企业和商户付款。

用户可以使用手机号绑定的 Raast ID 或银行账号转账。

巴林：Fawri+

Fawri+ 是巴林电子资金转账系统（EFTS）中的即时转账服务。

用户可通过参与银行或支付 App 使用 IBAN、手机号等信息付款。

巴西：Pix

Pix 是巴西央行推动的即时支付体系，底层由 SPI 等基础设施支持。

用户可以使用 CPF/CNPJ、手机号、邮箱、随机 Pix Key 或二维码付款。Pix 广泛用于个人转账和商户消费，并持续扩展自动付款等功能。

挪威：Vipps

Vipps 将个人转账、线上支付和商户二维码付款整合在同一 App 中，常用手机号识别收款人。

银行间即时转账基础设施通常称为 Straksbetalinger。

新加坡：FAST

FAST（Fast And Secure Transfers）是新加坡的银行间即时转账基础设施，支持参与机构之间全年实时转账。

FAST 是底层支付网络；面向用户的手机号别名服务主要是 PayNow。

新加坡：PayNow

PayNow 允许用户使用手机号、身份证号、企业编号或虚拟支付地址收付款，也支持 SGQR。

PayNow 的转账通常通过 FAST 等基础设施处理。它已与部分境外即时支付网络建立跨境连接。

新西兰：全年银行转账

新西兰银行间支付已覆盖一年 365 天处理。

用户主要使用银行账号转账；具体到账速度、额度和服务能力取决于付款银行与收款银行。

日本：Zengin System

全银系统（Zengin System）是日本银行间转账基础设施。“More Time System”将部分转账服务延长至夜间、周末和节假日。

用户端仍主要使用银行账号转账。日本二维码支付市场存在多个商业品牌，并没有类似 UPI 或 Pix 的单一统一品牌。

智利：TEF

Transferencias en Línea（TEF）支持银行之间的在线快速转账。

用户主要通过银行 App 使用收款人的银行、账户类型、账号和身份信息付款。

欧洲：SEPA Instant

SEPA Instant Credit Transfer（SCT Inst）是欧洲的欧元即时转账方案，通常要求收款人在 10 秒内取得资金，全年运行。

用户主要使用 IBAN 转账。TIPS、RT1 以及各国清算系统可以处理符合 SCT Inst 规则的交易。

欧盟法规要求相关即时转账收费不得高于同类普通转账，并逐步要求银行提供收款人姓名核验。

沙特阿拉伯：sarie

sarie 是沙特阿拉伯的即时支付系统，支持全年实时转账。

用户可以通过 IBAN、手机号等标识付款，具体入口由参与银行提供。

波兰：BLIK

BLIK 支持手机号转账、一次性代码付款、电商、线下商户和 ATM 操作。

Express Elixir 是波兰的银行间即时清算系统。BLIK 是面向用户的支付方案，两者不能直接等同。

泰国：PromptPay

PromptPay 支持使用手机号、身份证号、企业编号和二维码收付款，覆盖个人转账、政府付款和商户收款。

PromptPay 还与部分周边国家的即时支付及二维码网络连接。

澳大利亚：NPP、PayID 与 Osko

New Payments Platform（NPP）是澳大利亚的实时支付基础设施。

PayID 允许手机号、邮箱、ABN 等标识绑定银行账户；Osko 是建立在 NPP 上的消费级支付服务之一。不同银行 App 对产品名称的展示可能不同。

瑞典：Swish

Swish 是瑞典广泛使用的移动支付服务，支持手机号转账和二维码付款。

其银行间处理和结算依赖 BiR、RIX-INST 等基础设施。

瑞士：SIC IP 与 TWINT

SIC IP 是瑞士的即时支付基础设施，供金融机构处理全天候即时转账。

TWINT 是用户更熟悉的本地移动支付产品，支持手机号、二维码和商户付款；它与 SIC IP 并非同一层服务。

美国：FedNow

FedNow 是美国联邦储备银行运营的即时支付基础设施，支持参与存款机构全年实时处理付款。

用户不能直接在 FedNow 开户，需要通过已接入的银行或信用合作社使用。

美国：RTP

RTP 是 The Clearing House 运营的美国即时支付网络，支持即时入账、付款确认和 Request for Payment 消息。

RTP 与 FedNow 是两套并存的网络。金融机构需要分别选择接入。

美国：Zelle

Zelle 是由参与银行和信用合作社向用户提供的个人转账服务，通常使用邮箱或美国手机号识别收款人。

Zelle 不是 FedNow 或 RTP 的别名。付款通常难以撤回，因此只适合向认识和信任的人转账。

肯尼亚：PesaLink

PesaLink 连接肯尼亚的银行账户，支持使用银行账号或手机号进行全天候即时转账。

M-Pesa 是影响更广的移动货币体系，但它与银行间的 PesaLink 不是同一系统。

英国：Faster Payments

Faster Payments Service（FPS）支持个人、账单和企业即时或近即时付款。

用户通常使用 sort code 与 account number 转账。英国银行普遍提供收款人姓名核验，以降低误转和诈骗风险。

菲律宾：InstaPay

InstaPay 面向小额即时转账，用户可以通过银行或电子钱包账号付款。

它与适合批量、非即时交易的 PESONet 分工运行。

内地与香港：跨境支付通

跨境支付通（Payment Connect）是中国人民银行与香港金融管理局共同推动的快速支付互联安排，于 2025 年 6 月 22 日上线。它直接连接：

• 中国内地的网上支付跨行清算系统（IBPS）；
• 香港的快速支付系统“转数快”（FPS）。

用户通过参与银行的手机银行发起跨境汇款，不需要另外下载一个名为“跨境支付通”的 App。付款指令、货币兑换和资金入账由两地参与机构及支付系统完成。

两个方向

这里的“北向”和“南向”描述资金流向，不要与“跨境理财通”、沪深港通或债券通的同名方向混淆。

个人怎样使用

1. 确认付款银行和收款银行均已参与跨境支付通；
2. 在手机银行中找到“跨境支付通”或“跨境汇款”入口；
3. 填写收款人姓名、手机号、银行及账号等资料；
4. 选择汇款用途，查看汇率、手续费和预计到账金额；
5. 核对收款人后提交。

部分内地银行要求收款人首次接收北向汇款前，先登记英文姓名、手机号和银行卡号。各银行的入口、可用币种、登记流程和收费可能不同。

限额

个人业务应同时遵守监管限额和银行自行设置的交易限额：

• 北向个人汇款：香港居民经每家参与机构汇往内地的总额，通常为每日不超过等值 10,000 港元、每年不超过等值 200,000 港元。该额度独立于香港现有的人民币同名汇款额度；
• 南向个人汇款：受中国内地个人外汇管理规定约束，包括每人每年等值 50,000 美元的购汇便利化额度。部分银行另设单笔或单日限额，例如 10,000 元人民币；
• 银行可以设置更低的单笔、单日、月度或年度限额。

限额、参与机构和业务范围可能调整，实际应以付款银行提交交易时显示的规则为准。

它解决了什么问题

传统跨境汇款可能需要填写较多银行资料，并经过代理行或其他跨境通道。跨境支付通利用两地已有的快速支付基础设施，使小额汇款具有以下特点：

• 手机银行内直接办理；
• 通常实时或接近实时到账；
• 汇款前展示汇率、费用及收款金额；
• 周末和节假日也可能使用，但具体服务时段由银行决定；
• 支持个人转账，并逐步扩展发薪、教育、医疗和公共事业缴费等场景。

不等于什么

• 不是跨境理财通：跨境支付通用于付款和汇款，不是投资产品通道；
• 不是 CIPS：CIPS 是人民币跨境支付清算基础设施，服务范围和参与主体更广；
• 不是数字人民币跨境支付：跨境支付通连接的是 IBPS 与 FPS；
• 不是全球通用汇款网络：当前主要连接中国内地与香港，收付款机构必须参与该服务。

注意事项

跨境即时汇款一旦入账，通常难以撤回。付款前应核对收款人姓名、账号、币种、汇率和用途。不要因为“安全账户”“解冻资金”“退款验证”等理由向陌生人转账。

如果交易延迟或失败，应保存交易编号并联系付款银行。退汇时的到账金额可能受汇率变化和费用影响。

资料来源

• 香港金融管理局：跨境支付通
• 香港金融管理局：个人两地跨境汇款常见问题
• 中国政府网：跨境支付通于 2025 年 6 月 22 日上线

阿根廷：Transferencias 3.0

Transferencias 3.0 推动银行与电子钱包之间的即时支付互操作。

用户可以使用 CBU、CVU、账号别名或统一二维码付款。

阿联酋：Aani

Aani 是 Al Etihad Payments 推出的即时支付平台。

它支持手机号、邮箱、二维码和付款请求，并逐步连接当地银行与支付机构。

韩国：Electronic Banking System

韩国较早实现近实时电子银行转账。用户主要通过银行 App、银行账号或手机号完成转账。

Electronic Banking System、CD/ATM 网络等基础设施共同支持当地高度普及的电子支付服务。

马来西亚：DuitNow

DuitNow 是马来西亚面向用户的即时支付品牌，支持手机号、身份证号、护照号、企业注册号和二维码。

其底层实时支付平台是 RPP。DuitNow QR 为银行和电子钱包提供统一二维码受理。

游戏

电子游戏相关的介绍、评测与笔记。

Lost Life 游戏介绍

《Lost Life》游戏介绍：一位女高中生的黑暗日常模拟

在2025–2026年间突然爆火的移动端独立游戏《Lost Life》（中文常被直译为《迷失的生命》或直接叫“Lost Life小女孩“），是一款把“日常模拟“与“心理恐怖“极端混合的争议性作品。它最广为人知的版本是一款安卓APK游戏，由名为Shikstoo Games（或类似小团队）开发，目前最新版本已更新到1.9x系列。

核心设定与类型

• 类型：第三人称3D模拟养成 + 心理恐怖 + 选择驱动叙事 + 部分成人向互动（dating sim元素）
• 视角：主要以第三人称操控/观察一名外表清纯可爱的女高中生
• 表面玩法：看似是“女高中生的一天“——上学、回家、换衣服、和同学/老师互动、看手机、睡觉……
• 真实内核：这是一款披着日常模拟外衣的极重口心理惊悚/虐待向游戏。玩家的几乎所有操作最终都会导向对女主角的精神与肉体进行不同程度的“伤害“与“侵蚀“。

游戏最著名的宣传语之一就是：

“她的每一次哭泣、每一次颤抖、每一次精神崩溃，都会直接影响后续剧情走向与可解锁的内容。”

故事与世界观（无剧透版）

你扮演的不是“英雄“，而更像是一个拥有控制权的“观察者/施虐者“。
女主角表面上过着普通女高中生的生活，但随着日子一天天过去，你会逐渐发现：

• 她似乎被困在某种循环或诅咒之中
• 周遭人物（同学、老师、陌生人）逐渐显露出扭曲的一面
• 她的心理数值（恐惧、绝望、依赖、破碎度等）是游戏最核心的隐藏参数
• 你的每一个选择（温柔对待 / 忽视 / 霸凌 / 更进一步的侵犯）都会以指数级方式影响她的精神状态

当“心之极“或类似的精神条彻底归零时，会触发不同的Bad End，其中大部分极其血腥、暴力且带有强烈心理冲击。这些结局也正是让许多玩家又爱又恨的原因。

游戏特色机制

1. 情绪实时影响系统
   女主角的情绪不是摆设——她会真的哭、发抖、眼神空洞、自残倾向，甚至主动求死。很多高好感/高破碎的演出都做得很细腻（也因此尺度很大）。

2. 多重结局与高重玩价值
   据玩家社区统计，目前已知结局超过15–20种，从“相对温柔的共生结局“到“极度扭曲的支配结局“再到“彻底毁灭“，几乎没有真正意义上的“Happy End“。

3. 服装与道具收集
   猫耳、眼镜、校服、睡衣、泳装……这些看似萌系的元素，在不同精神状态下会被赋予完全不同的含义（从可爱→病娇→绝望的象征）。

4. 训练/投影/影片系统
   这是最核心也最具争议的玩法之一。玩家可以通过某些手段“记录“女主角的崩溃瞬间，然后反复播放给她看以提升/破坏好感度。这套系统几乎是全游戏最病态也最上头的地方。

受众与争议

《Lost Life》几乎是2025–2026年最典型的两极分化手游：

喜欢的人会说：

• “演出和心理刻画细腻到可怕”
• “选择带来的因果报应真的很带感”
• “病态美学天花板”

讨厌的人会说：

• “纯纯的虐待模拟器+软色情”
• “三观炸裂，玩完有心理阴影”
• “就是打着恐怖旗号的变态向作品”

官方也明确标注：18+ / 心理承受力较弱者慎入。

目前状态（2026年3月）

• 主要流传渠道仍是各种第三方APK网站（官方Google Play版本功能被大幅阉割）
• PC模拟器玩家也很多，常搭配存档修改器直接跳到高破碎/高好感路线
• B站、抖音、小红书上存在大量“全结局实录““一键存档包”“保姆级攻略”
• 部分玩家自发汉化并整理了全流程图，甚至有人做了“最温柔路线““最虐路线“对照表

一句话总结《Lost Life》：

它不是给你带来快乐的游戏，而是让你直视人性阴暗面、并用可爱少女的外壳狠狠戳穿你的道德底线的游戏。

你敢玩吗？

（完）

History

【耶鲁大学公开课】英国近代史（全25讲）

law

Literature

【耶鲁公开课 文学相关课程 6门课132集全】中英双语字幕

math

Media

SOC 119 Fall 2023 Full Lectures (Chronological Order)

媒介素养 -01- 第一课“短注意”与娱乐至死：我们为什么讨厌严肃的东西

【完结-双语】十分钟速成课-传播学(媒介素养)(12集全+预告)

怎样证明一个国家不存在？阴谋论的“芬兰实验”

罚10亿美元，能不能阻止一个胡说八道的自媒体？美国阴谋论网红Alex Jones的起落

Music

英皇乐理考级线上模拟考试系统 Piano Abrsm

Music Theory

好和弦的《學鋼琴完全指南》！想學鋼琴嗎？看這部就好～

Music Theory in 16 Minutes

Learn music theory in half an hour.

A Beginner’s Guide to Music Theory

【耶鲁大学】公开课 Introduction To Classical Music 古典音乐

Finger

[成人零基础学钢琴，必学六种指法！（顺指、穿指、跨指、扩指、同音换指、缩指）]（https://www.bilibili.com/video/BV1YG4y1g7kn/）

• 顺指
• 穿指
• 跨指
• 扩指
• 轮指
• 缩指

政治

政治哲学、经济学相关的思考与笔记。

目录

• 数字民主：从选举信息平台到公共参与基础设施
• 从非零和博弈到结构性不平等
• 从马太效应反对平均主义

从非零和博弈到结构性不平等

人类社会不是一个总量固定的分配游戏。资源虽然有限，生产、技术、知识与组织却能够创造增量。因此，社会整体更接近一个同时包含正和创造、零和分配和负和冲突的复杂系统。

这个判断并不意味着分配矛盾不重要，也不意味着社会能够自然走向平等。恰恰相反：正和增长可以与结构性不平等同时存在。理解现代社会的关键，不是在“零和”与“非零和”之间二选一，而是区分价值创造、利益分配和规则控制三个层次。

一、社会为何不是纯粹的零和博弈

零和博弈要求参与者的收益总和固定：一方增加多少，另一方就必须减少多少。这种结构存在于赌博、名额竞争、固定资产争夺等局部情境，但不能完整描述社会生产。

农业技术可以提高单位土地的产出，机器可以放大劳动效率，知识能够以极低的边际成本传播，分工与交换可以使不同参与者同时获益。人类并非只在切分现成的蛋糕，也在不断改变蛋糕的大小和构成。

即使从能量守恒出发，也不能推出经济活动必然是零和的。社会没有创造物理意义上的能量，却能改善能量和物质的组织、转化与利用方式。相同的资源经过技术、知识和制度的重新组合，可以产生完全不同的使用价值。物理量守恒不等于经济价值固定。

因此，更准确的描述是：

人类社会以有限的物质和能量为基础，通过知识、技术、协作与制度创造新的可用价值。

二、剩余价值理论揭示了什么

马克思的剩余价值理论常被理解成一种零和模型：资本家的利润来自劳动者未获得的价值，资本所得越多，劳动所得就越少。

这种理解抓住了分配冲突，却容易把局部结构扩大为整个经济系统。在生产层面，劳动、资本、技术和组织共同参与价值创造，总产出并不固定；在既定产出下，工资和利润的份额则可能呈现明显的此消彼长。由此可以把经济过程分成三层：

1. 生产层：技术、资本与协作扩大总产出，主要表现为正和关系。
2. 分配层：工资、利润、税收等争夺既定产出的份额，可能近似零和。
3. 制度层：所有权、议价能力和政治权力决定分配规则由谁制定。

剩余价值理论的贡献，是指出非零和生产并不会自动带来公平分配。它提出了一个真实而长期存在的问题：新增价值由谁创造、由谁占有、按照什么规则分配。

但它没有给出一个可以永久消除分配矛盾的技术答案。任何复杂社会都要面对稀缺、激励、信息和权力约束。问题可以被改善，却很难被一次性解决。

三、资本并不天然等同于剥削

资本既是一种所有权关系，也是一种生产工具。机器、基础设施、技术、管理与风险承担能够提高劳动生产率，使劳动者和投资者都比缺少这些条件时获得更多收益。因此，雇佣关系可能包含权力不对称和利益冲突，也可能形成真实的互利合作。

如果把所有资本收益都预先定义为剥削，就会忽略资本扩大生产能力的作用，也难以解释现代社会中大量自愿合作与双赢交换。反过来，如果只强调合作和增长，又会忽视垄断、议价能力失衡以及劳动者无法分享生产率增长的问题。

较合理的分析应同时承认两点：资本能够创造增量，也能够凭借所有权和制度优势攫取过高份额。真正需要判断的不是资本是否具有“原罪”，而是资本收益在多大程度上来自生产贡献、风险承担、垄断地位或规则控制。

四、社会民主主义的现实回答

欧洲社会民主制度没有消灭资本，也没有取消市场，而是通过累进税收、遗产税、劳动保护、公共教育、医疗保障和社会福利限制资本优势的无限累积。

这种制度安排试图保留市场的价格信号和创新激励，同时降低财富世袭、机会封闭和生存风险。它不是对生产关系的终极解决，而是一种持续调整的混合机制：市场负责大量资源配置，国家负责公共品、再分配与规则维护，社会共同体补充两者无法覆盖的领域。

这说明社会主义的一部分目标——提高公共性、降低生存焦虑、限制结构性支配——可以通过制度逐步实现，而不必以彻底取消市场和私有财产为前提。

五、阶级为何难以彻底消亡

即使货币财富被重新分配，人与人之间仍然存在能力、健康、兴趣、地理位置、家庭环境和偶然机会的差异。更重要的是，这些差异可以积累并代际传递。

家庭传递的不只是金钱，还包括语言习惯、教育方式、知识经验、社会网络、声誉和行为模式。这些文化资本与社会资本有时比货币财富更稳定，也更难通过一次再分配消除。取消私人生产资料并不会自动取消组织权力、知识差异和家庭影响；旧的阶级结构可能消失，新的分层形式仍可能出现。

家庭也不能在不付出巨大人性和自由代价的情况下被彻底消灭。父母自然会把自己拥有的资源、经验与关怀传给子女。正是这种传递维持了文明的连续性，同时也造成机会的不平等。这是一个无法彻底消除、只能加以约束的结构性矛盾。

因此，“阶级消亡”如果被理解为所有稳定分层和支配关系的永久终结，便近似一种无法验证的终点承诺。它与宗教天堂或传统“大同”理想具有相似结构：现实中的矛盾将在未来的完美状态中被彻底解决。

理想可以提供批判现实的尺度，却不能代替对稀缺、激励、信息与权力机制的具体说明。

六、按需分配的边界

按需分配在局部领域已经存在。公共教育、基础医疗、消防、开源软件和数字公共品都不同程度地按照需要而非个人支付能力供给。

但完整意义上的按需分配面临三个约束：

• 需求可能持续扩张，且难以被客观测量；
• 土地、时间、注意力、优质服务等资源始终稀缺；
• 分配者拥有判断需求优先级的权力，可能形成新的等级结构。

因此，人类可以扩大非市场分配领域，却很难在所有领域完全取消价格、交换和优先级选择。可行方向不是一个纯粹制度取代另一个纯粹制度，而是在市场、国家与公共机制之间不断调整边界。

七、差异为何会累积成结构性不平等

差异并不可怕，真正决定结果的是差异背后的反馈结构。当一次微小优势能够提高下一轮获得资源的概率时，系统就会形成累积优势：

初始差异 → 更多资源 → 更高成功概率 → 更大差异

财富可以带来投资收益，良好教育可以增加进入更好学校和职业的机会，平台的早期用户优势可以通过网络效应转化为垄断。最初甚至是随机产生的差异，也可能在多轮正反馈后形成巨大的结果差距。

然而，极端分化并非不可避免。税收和公共服务可以降低财富差距的累积速度，反垄断和市场竞争可以打破既有优势，技术变迁可以重置产业格局。现实社会的状态取决于放大机制与抑制机制的共同作用：

随机差异 + 正反馈 + 抑制机制 = 动态而非固定的不平等。

八、从消灭差异转向限制支配

如果差异、家庭传递与累积效应无法彻底消失，那么社会正义的目标就不应是制造一个绝对无差异的社会，而应是防止差异无限转化为结构性支配。

这意味着：

• 保障基本生活，使弱势者不因缺少资源而失去人格和自由；
• 提供普遍教育、医疗与法律保护，扩大进入正反馈循环的机会；
• 限制垄断、世袭特权和权力寻租，保持社会流动性；
• 保留合理的回报差异，为创新、劳动与长期投资提供激励；
• 通过民主和法治持续修正分配规则，而不许诺一次性解决所有矛盾。

社会主义作为改善不平等、扩大公共品和约束资本权力的制度方向具有现实可能；共产主义如果被定义为无阶级、按需分配以及结构性矛盾的最终消失，则面对难以克服的人性与系统约束。

结语

人类社会既不是纯粹的零和竞技场，也不会因为生产增长而自然成为人人受益的共同体。生产可以是正和的，分配可以是零和的，冲突可以是负和的，权力还会决定谁能定义游戏规则。

差异具有累积效应，分层具有自我再生产能力。成熟的政治目标不是许诺差异和矛盾的终结，而是建立足够有效的制度，使合作创造的增量被更广泛地分享，使任何优势都无法轻易固化为不可挑战的支配。

社会进步不是抵达一个永恒完美的终点，而是在创造、分配、自由与平等之间持续进行可以纠错的调整。

数字民主：从选举信息平台到公共参与基础设施

数字民主不是简单地把投票搬到互联网上，也不等于政府开设网站或社交媒体账号。它是数字技术进入民主制度之后形成的一整套新机制，包括选举信息公开、选民登记、政治讨论、公共协商、意见征集、议会透明、电子投票和结果监督。

哥伦比亚与秘鲁的选举结果网站提供了一个具体切口。一个稳定、统一、能够持续访问的结果平台，看似只是政府网站设计，实际上影响公众如何验证选举、媒体如何引用数据、研究者如何比较历史结果，以及社会能否形成共同认可的事实基础。

数字民主首先是一种信息基础设施，然后才是一种投票技术。

一、选举结果网站为何属于民主制度

哥伦比亚国家民事登记局使用统一入口公布选举结果：

https://resultados.registraduria.gov.co/

总统选举第一轮、第二轮及其他选举被纳入同一套信息体系。稳定入口具有几项制度意义：

• 选民只需记住一个官方来源；
• 媒体可以长期引用一致的网址；
• 不同轮次的数据结构便于比较；
• 历史结果更容易保存和审计；
• 非官方传言可以由权威数据及时纠正。

如果每次选举都建立新的站点，短期也能完成结果发布，但网址、界面和数据格式的频繁变化会增加验证成本。第一轮与第二轮的信息被割裂，历史记录也可能随着临时项目下线而消失。

因此，统一平台与临时项目的区别不只是技术路线：

选举公信力不仅来自计票过程本身，也来自公众能否方便地接近、理解和复核计票信息。

二、数字民主不等于电子投票

人们谈到数字民主时，常常首先想到网上投票。但民主过程远比投票日更长：

1. 公民获得可靠的公共信息；
2. 候选人与政党表达政策主张；
3. 社会进行讨论、组织和协商；
4. 选民登记并完成投票；
5. 计票结果被公布、复核与确认；
6. 当选者接受持续监督；
7. 公民参与立法、预算和政策反馈。

电子投票只是其中一个环节，而且往往是安全风险最高、争议最大的一环。数字技术更稳妥的价值，可能首先体现在选举信息公开、结果可视化、议会记录检索和公共意见征集上。

数字民主的成熟程度，不应以“能否用手机投票”作为唯一标准，而应看技术是否降低了公民参与和监督公共权力的成本。

三、数字民主的五个层次

1. 信息公开

最基础的数字民主，是让法律、预算、候选人信息、投票规则、议会记录和选举结果能够被公众及时获取。

公开不等于上传文件。真正有效的信息公开还要求：

• 使用稳定网址和统一入口；
• 同时提供适合阅读与机器处理的数据；
• 解释统计口径和法律效力；
• 保留历史版本和修改记录；
• 为残障人士和不同语言群体提供可访问形式。

如果信息虽然公开，却只能在杂乱页面或扫描文件中寻找，制度上的透明仍然很有限。

2. 公众表达

数字渠道可以降低公民向政府表达意见的成本，例如网上请愿、政策留言、意见征集和议员联络平台。

但表达渠道只有与正式程序连接才有意义。平台需要说明意见如何被归类、由谁处理、何时答复，以及是否影响最终决策。否则，参与容易沦为没有制度反馈的情绪收集。

3. 公共协商

民主不只是把个体偏好相加，也包括不同群体在共同事实基础上交换理由。数字平台可以帮助更多人跨越时间和地理限制参与讨论，但也容易受到情绪传播、群体极化和有组织操纵的影响。

有效协商需要议题说明、证据材料、主持规则、身份和利益披露，以及对少数意见的保护。参与人数多并不自动意味着讨论质量高。

4. 共同决策

参与式预算、地方公投和党内初选等机制，可以让公民对有限范围的公共事务直接作出选择。数字工具能够扩大参与规模、降低统计成本，并及时展示不同方案的支持情况。

共同决策必须明确权力边界：哪些决定具有法律约束力，哪些只是咨询意见；谁有资格参与；结果如何执行；少数人的基本权利如何保护。

5. 持续监督

选举赋予权力，监督限制权力。开放预算、公共采购、政治献金、议会表决和官员利益申报等数据，可以使记者、研究者和普通公民持续观察政府行为。

数字化的真正优势，是把监督从少数时间点扩展到整个任期。一个只在选举日开放参与、选后缺少透明度的制度，仍然不是完整的数字民主。

四、各国尝试所代表的不同方向

爱沙尼亚：电子身份与网络投票

爱沙尼亚将数字身份、电子签名和在线公共服务结合，并把网络投票纳入选举制度。这条路径表明，电子投票不能孤立建设，它依赖成熟的身份体系、法律效力、安全能力和长期社会信任。

其经验的重要性不在于证明所有国家都应立即采用网络投票，而在于说明数字民主是一套制度生态，而不是一个投票应用。

英国：开放信息与电子请愿

英国通过统一政府门户、议会信息公开和电子请愿机制，为公众提供较清晰的参与入口。达到一定支持门槛的请愿可以得到政府回应，并可能进入议会讨论。

这种模式连接了低门槛表达与正式政治程序。它同时说明，签名数量只是议程设置工具，不能替代议会审议、证据判断和权利保障。

台湾地区：数字协商实验

台湾地区的一些实践重视在线意见整理、政府回应和公民协作，尝试把网络讨论从简单的赞成或反对转变为寻找可形成共识的具体主张。

这类实践的价值在于改进协商质量，但是否能够长期发挥作用，仍取决于政府部门是否愿意回应，以及参与结果能否进入正式决策流程。

巴西：参与式治理与数字渠道

巴西长期存在参与式预算和社会参与机制，数字渠道为扩大参与范围提供了新工具。它说明数字民主不一定从国家级电子投票开始，也可以从地方预算、社区事务和具体政策协商逐步发展。

拉丁美洲：从选举透明走向持续参与

拉丁美洲不少国家已经能够在线发布选举结果、候选人信息和投票站数据，但选举之外的政策参与、数据连续性和跨机构标准仍可能不足。

哥伦比亚的统一选举结果入口体现了较好的平台意识，但单一网站不能代表整个数字民主水平。还需要考察政治资金是否透明、议会数据能否获取、公众意见是否得到回应，以及弱势群体能否平等参与。

五、选举结果平台应如何设计

一个可信的官方结果平台至少应满足以下要求。

权威来源清晰

域名、管理机构和法律依据应明确，搜索引擎和政府官网都应能稳定指向同一入口，避免仿冒网站借机传播错误结果。

区分不同计票阶段

平台应清楚区分快速统计、正式复核和最终认证，解释每种结果的法律地位。数字传播速度很快，如果界面没有标明数据性质，公众容易把暂时领先误解为最终当选。

提供足够的细分数据

全国总数之外，还应允许按地区、选区和投票站查询。在保护秘密投票的前提下，足够细的数据有利于政党、观察组织和公民进行交叉核验。

同时服务普通公众与专业监督者

普通用户需要清晰图表和简明解释，研究者与媒体则需要结构化数据、下载接口、统计口径和更新时间。两种需求不应相互替代。

保存历史记录

民主制度需要公共记忆。选举结束后，结果页面、原始数据、规则说明和更正记录都应持续保存，而不是随着项目验收或服务器迁移而消失。

对错误进行透明更正

计票数据可能被复核和修正。平台应保留更新时间、修正原因和版本变化，而不是静默覆盖旧数据。可追溯的更正不会削弱可信度，反而是制度能够纠错的证据。

六、电子投票的特殊风险

纸质选票的统计可能缓慢，却具有直观、可观察和可重复计票的优势。电子投票提高便利性，但会引入普通选民难以独立理解和验证的技术层。

主要风险包括：

1. 身份与匿名的冲突：系统既要确认选民资格，又不能把身份与选票内容关联。
2. 终端安全：个人电脑和手机可能受到恶意软件控制。
3. 服务器攻击：系统可能遭遇入侵、拒绝服务或内部人员滥权。
4. 秘密投票环境消失：远程投票时难以防止家庭、雇主或组织胁迫。
5. 审计困难：没有独立物理记录时，公众很难验证软件是否正确运行。
6. 信任脆弱：即使没有真实攻击，仅仅是无法证伪的怀疑也可能损害选举合法性。

因此，选举数字化应区分“信息发布”和“选票数字化”。前者通常可以显著提高透明度，后者则必须经过更严格的安全论证、独立审计、纸质凭证和应急方案。

技术效率不能取代公众可验证性。

七、平台化可能扩大民主，也可能集中权力

数字平台能够扩大参与，却同时掌握身份、数据、排序和传播规则。谁控制平台，谁就可能影响哪些议题被看见、哪些群体能够发声，以及什么行为被视为异常。

数字民主因此面临几类结构性风险：

• 数字鸿沟：缺少设备、网络或技能的人被排除；
• 平台操纵：排序算法放大极端内容或特定政治议程；
• 虚假参与：机器人、重复账号和组织化行动制造多数假象；
• 监控压力：实名参与可能使公民不敢表达反对意见；
• 数据滥用：政治立场和参与记录被用于画像或歧视；
• 多数暴政：即时投票压缩审议过程并伤害少数权利；
• 技术官僚化：平台规则由少数技术人员决定，却缺少民主监督。

所以数字民主不能只追求更多点击、签名和投票。它必须同时保护匿名表达、程序正义、少数权利和退出数字渠道的自由。

八、数字民主的制度原则

数字工具只有嵌入民主规则，才能真正改善民主。较稳健的制度应遵循以下原则：

可访问

服务应支持不同设备、语言和身体条件，并保留必要的线下参与方式。数字渠道应扩大参与，而不是成为新的资格门槛。

可验证

选举结果、统计方法、平台规则和数据变更应允许独立机构、政党、媒体和公众进行核验。

可解释

公民应当知道意见如何处理、算法如何排序、结果如何产生，以及某项自动决定为何影响自己。

可申诉

身份识别失败、内容误删、投票异常和数据错误都必须有清晰的人工救济渠道。

可追责

平台必须有明确的法定责任主体。不能让政府部门、承包商和算法相互推卸责任。

最小化数据

参与民主活动不应要求收集与目的无关的数据，政治观点和投票秘密应得到最高程度的保护。

开放且可替换

关键标准、数据格式和审计接口应保持开放，避免民主基础设施被单一供应商长期控制。

九、评价数字民主的真正标准

一个国家拥有精美的选举网站、政务应用甚至网络投票，并不必然意味着民主质量更高。评价数字民主至少要追问：

• 公民能否获得完整、准确、持续可访问的信息？
• 官方结果是否能够被独立复核？
• 参与是否与正式决策程序连接？
• 政府是否必须说明采纳或拒绝意见的理由？
• 少数群体和数字弱势者是否受到保护？
• 平台本身是否接受法律、技术和公众监督？
• 数字工具是在分散权力，还是在强化监控和行政控制？

数字化既可以降低公民监督政府的成本，也可以降低政府监控公民的成本。两种可能性始终同时存在。

结语

哥伦比亚统一选举结果平台的启示，不只是“网站设计得更好”，而是民主信息需要稳定、连续、可验证的公共基础设施。选举结果只有被清楚解释、长期保存并允许复核，才能转化为社会共同承认的政治事实。

数字民主的发展也不应止于选举结果发布，更不应被简化为手机投票。它应贯穿信息获取、公共讨论、政策协商、共同决策和持续监督的全过程。

真正值得追求的，不是参与次数最多或技术最先进的民主，而是一个让更多人能够知情、表达、协商和监督，同时仍能保护秘密、权利与程序正义的制度。数字技术可以扩展民主，但只有民主原则才能约束数字权力。

从马太效应反对平均主义

一、马太效应的核心内涵

马太效应（Matthew Effect）源于《圣经·马太福音》：“凡有的，还要加给他，叫他有余；凡没有的，连他所有的也要夺去。”

美国社会学家罗伯特·莫顿（Robert K. Merton）于1968年将这一概念引入科学社会学，用以描述优势积累现象：已经获得声誉和资源的科学家更容易获得新的资源和认可，而未成名者则难以突破。

二、马太效应的普遍性机制

马太效应并非偶然，而是根植于多种系统的正反馈机制：

核心机制：初始微小差异 → 资源倾斜 → 能力/产出差距扩大 → 下一轮资源进一步倾斜

三、平均主义的悖论：为何干预可能适得其反

1. 破坏信号机制，降低整体效率

市场通过回报差异传递信号：哪些领域、哪些能力更有价值。平均主义抹平差异，等于屏蔽价格信号。

• 若无论创新与否回报相同，创新动力衰减
• 若无论努力与否收入相等，努力意愿下降
• 结果：社会整体产出萎缩，“蛋糕“变小，最终人人受损

哈耶克警告：试图消灭不平等往往以普遍贫困告终。

2. 抑制人力资本投资

教育、技能提升需要成本（时间、金钱、机会成本）。马太效应下，高回报激励个体进行人力资本投资；平均主义下，投资边际收益趋零，理性人选择减少投资。

长期后果：社会人力资本存量下降，创新能力衰退。

3. 逆向选择：优秀人才外流

若某 jurisdiction 推行严格的平均主义政策，而其他地区保持竞争性回报：

• 高能力个体“用脚投票“，迁移至回报与贡献匹配的地区
• 留下的群体平均素质下降
• 地区竞争力进一步滑坡

历史例证：计划经济时代的人才流失与效率困境。

4. 权力替代市场，滋生新不平等

平均主义需由权力中心执行资源再分配。但：

• 信息问题：中心无法掌握分散的个体偏好与能力
• 激励问题：分配者缺乏有效约束，易形成特权阶层
• 结果：名义上的平均主义，实际演变为权力-裙带资本主义

四、更优的路径：机会平等而非结果平等

反对平均主义，不等于拥护放任自流。基于马太效应的洞见，政策应聚焦于：

1. 阻断代际传递：遗产税、优质教育普惠，防止“出身决定命运“
2. 保障起点公平：基本医疗、营养、早期教育，确保禀赋不被浪费
3. 维护竞争秩序：反垄断、知识产权保护，防止马太效应走向垄断僵化
4. 兜底而非封顶：社会保障网托底，但不限制上限

关键区分：

• 机会平等：让赛跑者在同一起跑线出发（公平）
• 结果平均：让所有人同时冲线（不可能且有害）

五、结论

马太效应揭示了复杂系统中正反馈的必然性。试图以平均主义强行压制这一规律，如同逆水行舟：

• 短期可能缩小差距表象
• 长期必以效率损失、创新停滞、人才流失为代价

明智的政策不是对抗马太效应，而是引导其方向——让优势积累基于贡献与能力，而非出身与特权；让每个人都有机会进入正反馈循环，而非被永远锁定在低端均衡。

“我们不应追求让富人变穷，而应追求让穷人变富。”
—— 约翰·F·肯尼迪

SIM 卡

境外 SIM 卡保号规则与使用经验。

境外 SIM 卡保号规则

更新时间：2026-05-23

这篇记录偏向“低成本保号”和“接收短信验证码”的场景。境外预付费卡的规则经常调整，购买前最好再看一遍运营商官网、套餐条款和 App 内有效期。

先看结论

最省心的组合通常是：

1. 想要长期、便宜、规则清楚：优先 giffgaff。
2. 想要香港号或 eSIM：看 Club Sim，但要接受香港实名和服务包有效期。
3. 想要极低成本 eSIM：lifecell 可以考虑，但要能处理乌克兰运营商、支付和政策变动。
4. 已在荷兰或欧盟生活：Simyo 可用，但每半年要主动产生一次活动。
5. educom 更像奥地利本地学习/生活套餐，不是典型“保号神器”。

保号通用原则

• 不要只收短信：多数运营商要求“主动使用”或“付费活动”。接收短信、接收电话、Wi-Fi 下使用 WhatsApp/Telegram 通常不算。
• 设置日历提醒：把到期日前 30 天和 7 天各设一次提醒；跨国短信失败、支付失败都需要预留时间。
• 保存登录方式：保号卡本身常被用来收验证码，如果 App 登录也依赖这张卡，丢卡或失效后会很麻烦。
• 留一点余额：只靠“到期前再充值”风险更高。保号卡至少留够一两条国际短信或一次最低充值。
• 关注实名要求：香港、乌克兰、欧盟等地规则可能因监管变化调整。不要把“以前不用实名”的经验当作长期有效规则。
• 不要绑定唯一重要资产：银行、交易所、域名、主邮箱等关键账户，尽量配合硬件安全密钥、TOTP 或备用号码。

giffgaff

英国 O2 网络的虚拟运营商，长期被当作低成本英国号使用。它的规则清楚，余额不容易因为时间本身过期，保号成本低。

保号规则

giffgaff SIM 若连续 6 个月没有使用，会被视为 inactive，之后号码可能被回收。至少每 6 个月做一次以下任意动作即可：

• 拨打一个非免费号码；
• 发送一条 SMS/MMS；
• 使用一次移动数据；
• 购买 Airtime Credit；
• 购买 plan/goodybag。

接收短信、接收电话、使用 Wi-Fi 上的通讯软件不算有效活动。

成本与做法

最简单做法是先充值少量余额，然后每 5 个月发一条短信。短信费用按所在地和目的地变化，建议不要卡在第 180 天当天操作。

giffgaff 通常会在号码即将停用前发邮件提醒。要确认账户邮箱还能登录，并且邮件不会进垃圾箱。

注意事项

• 号码停用后通常不能恢复，号码回收后更难找回。
• 海外漫游发短信可能比英国本地更贵。
• 某些互联网服务会限制 VoIP/MVNO/境外号码注册，不能保证所有平台都能收验证码。

Club Sim

香港 CSL Mobile 旗下服务，优势是购买和管理相对方便，服务包很多，支持实体 SIM 和部分 eSIM 场景。它更像“按服务包有效期续命”的卡，而不是固定 0 月租保号卡。

保号规则

Club Sim 的有效期跟所购买的服务包相关。常见规则包括：

• 本地数据包常见有效期为 90 天；
• 部分漫游通行证或指定数据包有效期为 365 天；
• 未完成香港实名登记的预付费卡会被停用。

因此不要简单理解为“每年 6 港币保号”。实际最低成本取决于当时 App 里还能买到的最低价服务包。

成本与做法

如果只是保号，优先在 App 里找最低价、有效期最长的服务包，并记录服务包结束日期。香港本地数据包一般更适合短期使用；漫游 Pass 可能更适合跨境保留，但价格会随目的地和活动变化。

注意事项

• 香港预付费卡已实施实名登记。
• 服务包条款会更新，同一产品不同活动页可能有效期不同。
• 如果主要用于验证码，先测试目标平台是否接受香港号码。

lifecell

乌克兰运营商，支持 eSIM，用户圈常把它当作低成本海外号码。优点是价格低、线上化程度较高；缺点是官方英文资料不如 giffgaff/Simyo 清晰，且当地监管和战争环境会带来额外不确定性。

保号规则

常见说法是号码在充值后延长 365 天；新 eSIM/新号码若未按要求选择资费并充值，初始有效期可能较短。部分商家资料提到一次充值达到指定金额后，号码有效期会延长为 365 天。

实际应以 My lifecell App 或官方账户中显示的号码有效期为准。

成本与做法

低成本做法是购买 eSIM 后完成激活，选择便宜资费或按要求充值，之后每年提前充值一次。充值后立刻在 App 内确认号码有效期，不要只看支付成功页面。

注意事项

• 购买渠道很多，尽量选择能提供完整激活说明和售后支持的渠道。
• 支付卡、IP、语言和客服沟通可能是门槛。
• 乌克兰号码用于部分服务注册时可能被风控，需要先测试。

Simyo

Simyo 这里主要指荷兰 Simyo，而不是西班牙 Simyo。荷兰 Simyo 使用 KPN 网络，官方对预付费有效期说明比较明确。

保号规则

Simyo Prepaid 的余额在 SIM 保持活跃时长期有效。要保持活跃，至少每 6 个月做一次以下动作：

• 呼出电话；
• 发送短信；
• 使用移动数据；
• 购买数据包；
• 充值余额。

若 6 个月没有使用，预付费卡、号码和余额都可能失效。Simyo 通常会在约 5 个半月未使用时通过邮件提醒。

成本与做法

如果人在欧盟，半年发一条短信或使用少量数据即可。如果人在欧盟外，先确认漫游、短信资费和是否能成功注册网络；不能稳定漫游时，靠定期充值更稳。

注意事项

• 荷兰 Simyo 与西班牙 Simyo 规则不同，不要混用经验。
• 需要能访问 Mijn Simyo 或 App。
• 适合在荷兰/欧盟有实际使用需求的人；只为低成本保号，不如 giffgaff 直观。

educom

奥地利 educom 面向学生、教育人群和本地用户，提供月、学期、年等不同周期套餐，也有 basico 这类预付费基础资费。

保号规则

educom basico 页面说明：只要预付费卡内有余额，服务可以继续使用，但每个日历年至少需要一次服务使用，例如通话、短信或数据连接。

这使它并非完全“不使用也能保号”的卡，更适合作为奥地利本地号码或短中期学习生活卡。

成本与做法

如果已经有 educom，保号时每年主动产生一次服务使用，并确认账户余额和资费状态。若只是为了买一张长期收验证码的海外卡，优先级不高。

注意事项

• 套餐、资费周期和是否自动续费要看具体产品。
• 教育类优惠可能有身份、地区、支付方式要求。
• 长期海外闲置前，建议先问客服确认当前号码的停机/回收规则。

推荐维护方式

为每张卡建一个简单表格：

提醒周期建议比官方期限更短：

• 6 个月规则：每 5 个月操作一次；
• 365 天规则：每 10-11 个月操作一次；
• 90 天规则：每 75 天操作一次。

信息来源

• giffgaff Help：Why has my number been deactivated?
• Club Sim：Local Data Service Terms and Conditions
• Club Sim：Data Roaming Day Pass Terms and Conditions
• lifecell shop：Number choice
• lifecell eSIM seller terms reference：lifecell eSIM starter package
• Simyo：Prepaid
• Simyo：All about call credit and topping up
• educom：basico
• educom FAQ：Tarife

科技

API 设计规范

API 风格

REST API 规范

URL 设计

✅ 正确
GET    /api/v1/users              # 列表
GET    /api/v1/users/123          # 详情
POST   /api/v1/users              # 创建
PUT    /api/v1/users/123          # 全量更新
PATCH  /api/v1/users/123          # 部分更新
DELETE /api/v1/users/123          # 删除

❌ 错误
GET    /api/v1/getUsers           # 动词前缀
POST   /api/v1/user/create        # 包含动词
GET    /api/v1/users/123/delete   # 用 GET 执行删除

资源命名

HTTP 状态码

响应格式

// 成功 — 单个资源
{
  "data": {
    "id": "123",
    "name": "Alice",
    "email": "alice@example.com",
    "created_at": "2025-01-15T08:30:00Z"
  }
}

// 成功 — 列表（带分页）
{
  "data": [
    { "id": "123", "name": "Alice" },
    { "id": "456", "name": "Bob" }
  ],
  "pagination": {
    "page": 1,
    "per_page": 20,
    "total": 156,
    "total_pages": 8
  }
}

// 错误
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Invalid request parameters",
    "details": [
      {
        "field": "email",
        "message": "Must be a valid email address"
      }
    ]
  }
}

认证与授权

认证方式

JWT 最佳实践

Header:  { "alg": "RS256", "typ": "JWT" }
Payload: { "sub": "user-123", "exp": 1705312200, "scope": "read write" }
Signature: RS256(privateKey)

• 使用 RS256（非 HS256）— 密钥不共享
• 短过期时间（15 分钟）+ Refresh Token
• 包含 exp、iss、aud 声明
• 不要放敏感信息在 Payload（JWT 只编码不加密）

HTTP Header

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
Content-Type: application/json
Accept: application/json
X-Request-ID: 550e8400-e29b-41d4-a716-446655440000
X-Idempotency-Key: 6ba7b810-9dad-11d1-80b4-00c04fd430c8

分页

方案对比

Offset 分页

GET /api/v1/users?page=2&per_page=20

{
  "data": [...],
  "pagination": {
    "page": 2,
    "per_page": 20,
    "total": 156,
    "total_pages": 8
  }
}

Cursor 分页

GET /api/v1/users?cursor=eyJpZCI6MTIzfQ==&limit=20

{
  "data": [...],
  "pagination": {
    "next_cursor": "eyJpZCI6MTQzfQ==",
    "has_more": true
  }
}

版本控制

建议：URL 路径版本控制（/v1/、/v2/），简单直接。

版本演进策略

v1 → v2 过渡期：
1. v1 继续运行，标记 deprecated
2. v2 发布，提供迁移指南
3. 设置过渡期（6–12 个月）
4. 过渡期结束，下线 v1

速率限制

响应 Header

X-RateLimit-Limit: 1000         # 窗口内总限额
X-RateLimit-Remaining: 742      # 剩余次数
X-RateLimit-Reset: 1705312200   # 窗口重置时间（Unix 时间戳）
Retry-After: 30                 # 429 响应时，建议等待秒数

限流策略

幂等性

为什么需要

客户端 → POST /users → 201 Created
                        ↓ 网络超时，客户端未收到响应
客户端 → POST /users → ???  （重复创建？）

幂等 Key 机制

POST /api/v1/payments
X-Idempotency-Key: 6ba7b810-9dad-11d1-80b4-00c04fd430c8
Content-Type: application/json

{
  "amount": 99.99,
  "currency": "USD"
}

服务端逻辑：
1. 收到请求，检查 Idempotency-Key
2. 如果 Key 不存在 → 执行操作，存储结果
3. 如果 Key 存在 → 直接返回之前的结果
4. Key 过期后自动清理（建议 24–48 小时）

幂等性映射

错误处理

统一错误格式

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "The request is invalid",
    "details": [
      {
        "field": "email",
        "code": "INVALID_FORMAT",
        "message": "Must be a valid email address"
      },
      {
        "field": "age",
        "code": "OUT_OF_RANGE",
        "message": "Must be between 0 and 150"
      }
    ],
    "request_id": "550e8400-e29b-41d4-a716-446655440000",
    "doc_url": "https://api.example.com/docs/errors#VALIDATION_ERROR"
  }
}

错误码设计

格式: CATEGORY_SPECIFIC_ERROR

类别前缀:
  AUTH_     — 认证授权
  VALID_    — 参数校验
  NOTFOUND_ — 资源不存在
  RATE_     — 限流
  SYS_      — 系统错误

示例:
  AUTH_TOKEN_EXPIRED
  AUTH_INSUFFICIENT_PERMISSIONS
  VALID_MISSING_REQUIRED_FIELD
  VALID_INVALID_FORMAT
  NOTFOUND_USER
  RATE_LIMIT_EXCEEDED
  SYS_INTERNAL_ERROR

API 文档

OpenAPI (Swagger)

openapi: 3.1.0
info:
  title: User API
  version: 1.0.0
paths:
  /users/{id}:
    get:
      summary: Get user by ID
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: User found
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '404':
          description: User not found
components:
  schemas:
    User:
      type: object
      properties:
        id:
          type: string
        name:
          type: string
        email:
          type: string
          format: email

文档工具

性能优化

缓存

# 服务端响应头
Cache-Control: public, max-age=3600
ETag: "33a64df5"
Last-Modified: Wed, 15 Jan 2025 08:30:00 GMT

# 客户端请求头
If-None-Match: "33a64df5"
If-Modified-Since: Wed, 15 Jan 2025 08:30:00 GMT

# 304 Not Modified — 无变化，不返回 body

压缩

Content-Encoding: gzip
Content-Encoding: br          # Brotli（更小）
Transfer-Encoding: chunked    # 流式传输

字段筛选

GET /api/v1/users?fields=id,name,email
GET /api/v1/users?include=orders,profile

GraphQL vs REST

选型决策

场景？
├── 公开 API → REST（最通用）
├── 移动端/复杂前端 → GraphQL（精确获取）
├── 微服务间通信 → gRPC（高性能、强类型）
├── 全栈 TypeScript → tRPC（端到端类型安全）
├── 实时推送 → WebSocket 或 SSE
└── AI 流式输出 → SSE 或 WebSocket

参考资料

• REST API Design Best Practices
• GitHub REST API 文档
• Stripe API 设计参考
• Google API Design Guide
• Microsoft REST API Guidelines

后端框架对比

框架全景

后端框架
├── JavaScript / TypeScript
│   ├── Express
│   ├── Fastify
│   ├── NestJS
│   ├── Hono
│   └── Elysia (Bun)
├── Python
│   ├── FastAPI
│   ├── Django
│   └── Flask
├── Go
│   ├── Gin
│   ├── Echo
│   ├── Fiber
│   └── Chi
├── Rust
│   ├── Axum
│   ├── Actix Web
│   └── Rocket
├── Java
│   ├── Spring Boot
│   └── Quarkus
├── Ruby
│   └── Rails
└── PHP
    └── Laravel

Node.js / TypeScript

Express

import express from 'express';
const app = express();

app.get('/users/:id', (req, res) => {
  res.json({ id: req.params.id });
});

app.listen(3000);

Fastify

import Fastify from 'fastify';
const app = Fastify();

app.get('/users/:id', async (request, reply) => {
  return { id: request.params.id };
});

app.listen({ port: 3000 });

NestJS

@Controller('users')
export class UserController {
  constructor(private userService: UserService) {}

  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.userService.findOne(id);
  }
}

Hono

import { Hono } from 'hono';
const app = new Hono();

app.get('/users/:id', (c) => {
  return c.json({ id: c.req.param('id') });
});

export default app;

Node.js 框架选型

Express  — 遗留项目 / 中间件生态依赖
Fastify  — 高性能 / Schema 驱动
NestJS   — 大团队 / 企业级 / 需要架构约束
Hono     — 边缘 / Serverless / 极致轻量
Elysia   — Bun 生态 / TypeScript 极致体验

Python

FastAPI

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class User(BaseModel):
    id: int
    name: str

@app.get("/users/{user_id}")
async def get_user(user_id: int) -> User:
    return User(id=user_id, name="Alice")

Django

from django.http import JsonResponse
from django.urls import path

def user_view(request, user_id):
    return JsonResponse({"id": user_id})

urlpatterns = [
    path("users/<int:user_id>", user_view),
]

Flask

Python 框架选型

FastAPI  — 新项目首选 / AI 服务 / 高性能 API
Django   — 全栈 Web / 复杂业务 / 需要 Admin
Flask    — 微服务 / 轻量 API / 原型

Go

Gin

r := gin.Default()

r.GET("/users/:id", func(c *gin.Context) {
    c.JSON(200, gin.H{"id": c.Param("id")})
})

r.Run(":3000")

Echo

Fiber

Chi

Go 框架选型

Gin    — 通用首选 / 招人容易
Echo   — 追求 API 美学 / 性能
Fiber  — JS 转 Go / 极致性能
Chi    — 标准库兼容 / 轻量

Rust

Axum

use axum::{routing::get, Router};

async fn get_user(axum::extract::Path(id): axum::extract::Path<u32>) -> String {
    format!("User {id}")
}

#[tokio::main]
async fn main() {
    let app = Router::new().route("/users/:id", get(get_user));
    let listener = tokio::net::TcpListener::bind("0.0.0.0:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

Actix Web

Rust 框架选型

Axum     — 新项目首选 / Tokio 生态 / 类型安全
Actix    — 已有经验 / 需要 Actor 模型
Rocket   — 易用性优先 / 宏驱动

Java

Spring Boot

@RestController
@RequestMapping("/users")
public class UserController {

    @GetMapping("/{id}")
    public User getUser(@PathVariable Long id) {
        return new User(id, "Alice");
    }
}

Quarkus

Java 框架选型

Spring Boot — 企业标准 / 最大生态 / 招人容易
Quarkus    — 云原生 / Serverless / 极致启动速度

Ruby / PHP

Ruby on Rails

Laravel

性能对比（请求/秒，基准测试参考）

Rust (Axum/Actix) > Go (Gin/Fiber) > Node.js (Fastify) > Python (FastAPI) > Java (Spring Boot) > Ruby (Rails) > PHP (Laravel)
      500K+              200K+            80K+              50K+              30K+              15K+           10K+

注意：基准测试仅供参考，实际性能取决于业务逻辑、数据库、网络等。框架选择对大多数应用不是性能瓶颈。

选型决策

场景？
├── AI/ML 服务 → FastAPI（Python 生态、类型安全）
├── 高并发 API → Go (Gin) 或 Rust (Axum)
├── 企业级系统 → Spring Boot（最大生态）
├── 全栈 Web → Rails 或 Laravel（快速开发）
├── 边缘/Serverless → Hono 或 Quarkus
├── 微服务网关 → Go (Fiber) 或 Node.js (Fastify)
└── 不确定 → FastAPI（AI 时代）或 Spring Boot（企业时代）

按团队技术栈

参考资料

• Express 官方文档
• Fastify 官方文档
• NestJS 官方文档
• FastAPI 官方文档
• Django 官方文档
• Gin 官方文档
• Axum 官方文档
• Spring Boot 官方文档

云服务对比

主流云平台概览

核心服务对比

计算

选型建议：

• K8s 原生 → GKE（Google 是 K8s 创始者，托管质量最高）
• Serverless 容器 → Cloud Run / Fargate（免运维、按请求计费）
• 国内合规 → 阿里云 ECS / ACK

存储

数据库

选型建议：

• 全球分布式强一致 → Cosmos DB（多模型、多区域写入）
• PostgreSQL 兼容 + 性能 → Aurora / PolarDB（AWS 和阿里云的旗舰）
• 需要原生向量搜索 → AlloyDB / PolarDB（PG 兼容 + 向量扩展）

AI / ML

选型建议：

• 需要 GPT-4 级模型 → Azure OpenAI（唯一正规渠道）
• 需要多模型选择 → Bedrock（Claude、Llama、Mistral 多家模型）
• 国内合规 → 阿里云百炼（通义千问 + 开源模型）

网络

安全与身份

定价模式对比

省钱技巧：

• 生产环境用 预留/Savings Plan
• CI/CD 和批处理用 Spot/竞价实例
• 数据传输费用是最大陷阱 — 同区域内免费，跨区域/跨出口收费

混合云与多云

多云工具链：

• Terraform / Pulumi：IaC 跨云编排
• Kubernetes：容器化应用天然跨云
• Cloudflare / Fastly：CDN 层屏蔽底层云差异

国内 vs 海外选型

选型决策

业务场景？
├── 全球化 SaaS → AWS（最全）或 GCP（数据强）
├── 企业级 + 微软生态 → Azure
├── 国内合规 → 阿里云 / 腾讯云
├── AI/ML 优先 → GCP（Vertex AI）或 Azure（OpenAI）
├── 成本敏感 → 多云 + Spot + Savings Plan
└── 不确定 → 先上 AWS，后续可迁移（生态最大）

参考资料

• AWS 官方定价
• Azure 官方定价
• GCP 官方定价
• 阿里云定价
• [各平台 Free Tier 对比](https://free tier.dev/)

色彩系统

色彩基础

色彩模型

CSS 颜色格式

/* 命名色 */
color: red;

/* 十六进制 */
color: #FF5733;
color: #F53;           /* 简写 */

/* RGB / RGBA */
color: rgb(255 87 51);
color: rgb(255 87 51 / 0.8);  /* 带透明度 */

/* HSL / HSLA */
color: hsl(14 100% 60%);
color: hsl(14 100% 60% / 0.8);

/* OKLCH（推荐用于设计系统） */
color: oklch(70% 0.15 30);

/* color-mix（CSS 原生混合） */
color: color-mix(in oklch, #FF5733 50%, #3366FF);

色彩理论

色轮与配色方案

              0° 红
             /    \
        330° 紫    30° 橙
           |        |
        270° 蓝    90° 黄
           \        /
        210° 青    150° 绿
             \    /
             180°

设计系统色彩架构

典型结构

Design Token
├── Primitive（原始色）
│   ├── blue-50, blue-100, ... blue-900
│   ├── red-50 ... red-900
│   └── neutral-50 ... neutral-900
├── Semantic（语义色）
│   ├── primary / secondary / tertiary
│   ├── success / warning / error / info
│   ├── background / surface / card
│   └── text-primary / text-secondary / text-disabled
└── Component（组件色）
    ├── button-primary-bg
    ├── input-border
    └── navbar-bg

Tailwind CSS 色阶系统

无障碍 (WCAG)

对比度要求

常见对比度参考

黑 #000000 on 白 #FFFFFF — 21:1 ✓ AAA
灰 #767676 on 白 #FFFFFF — 4.5:1 ✓ AA
蓝 #0066CC on 白 #FFFFFF — 5.9:1 ✓ AA
红 #D32F2F on 白 #FFFFFF — 5.6:1 ✓ AA

实用工具

• WebAIM Contrast Checker
• Chrome DevTools → Rendering → Emulate vision deficiencies
• Figma 插件：Stark、A11y

主流设计系统色彩对比

Material Design 3 (Google)

Primary:     oklch(0.55 0.20 265)  — 从 dynamic color 提取
On Primary:  oklch(0.98 0.00 0)
Primary Container: oklch(0.85 0.12 265)
Surface:     oklch(0.98 0.00 0)

特点：dynamic color（壁纸/图片提取品牌色）、tonal palette（13 级色调）

Fluent UI 2 (Microsoft)

Brand Primary:   #0078D4
Neutral Primary: #242424
Stroke 1:        #D1D1D1
Surface:         #FFFFFF

特点：中性为主、品牌色克制使用、强调可访问性

Apple HIG

System Blue:    #007AFF
Label:          #000000
Secondary Label: #3C3C4399
Separator:      #3C3C4349
System Gray:    #8E8E93

特点：语义色命名、不强调品牌色、依赖系统自动适配深浅模式

深色模式设计

核心原则

1. 不要简单反转：白底黑字反转成黑底白字会太刺眼
2. 降低饱和度：深色背景上高饱和色会“发光“
3. 使用灰色层级：#121212 → #1E1E1E → #2C2C2C → #383838
4. 阴影变光晕：深色模式用发光（glow）替代阴影（shadow）

色彩调整策略

CSS 色彩工具函数

/* oklch — 感知均匀，最适合设计系统 */
:root {
  --primary: oklch(0.55 0.20 265);
  --primary-hover: oklch(0.48 0.22 265);  /* 更暗 */
  --primary-light: oklch(0.85 0.12 265);  /* 更亮 */
}

/* color-mix — 原生混合，无需预计算 */
.btn-primary:hover {
  background: color-mix(in oklch, var(--primary) 80%, black);
}

/* light-dark() — 浅深模式自动切换 */
:root {
  color-scheme: light dark;
}
body {
  color: light-dark(#1a1a1a, #e0e0e0);
  background: light-dark(#ffffff, #121212);
}

/* relative color syntax — 相对色彩变换 */
:root {
  --primary-h: oklch(from var(--primary) h s l);
  --primary-saturate: oklch(from var(--primary) h calc(s * 1.2) l);
}

调色工具

配色实践

快速建立品牌色

1. 选定一个主色（Primary）
2. 基于主色生成 10 级色阶（50–950）
3. 选择互补或类似色作为 Secondary
4. 灰色中性色（Neutral）用于文本和背景
5. 语义色：Success (绿)、Warning (橙)、Error (红)、Info (蓝)
6. 验证对比度（WCAG AA 最低）
7. 测试深色模式

常见错误

参考资料

• Material Design 3 — Color System
• WCAG 2.1 — Understanding Contrast
• OKLCH 在 CSS 中的使用
• A Guide To Color Accessibility

数据库技术对比

数据库分类

数据库
├── 关系型 (RDBMS)
│   ├── PostgreSQL
│   ├── MySQL
│   ├── SQLite
│   └── Oracle / SQL Server
├── 文档型 (Document)
│   ├── MongoDB
│   └── CouchDB
├── 键值型 (Key-Value)
│   ├── Redis
│   └── DynamoDB
├── 列族型 (Column-Family)
│   ├── Cassandra
│   └── HBase
├── 时序型 (Time-Series)
│   ├── InfluxDB
│   ├── TimescaleDB
│   └── QuestDB
├── 图数据库 (Graph)
│   ├── Neo4j
│   └── ArangoDB
├── 向量数据库 (Vector)
│   ├── Pinecone
│   ├── Milvus
│   ├── Weaviate
│   └── Chroma
└── NewSQL
    ├── CockroachDB
    ├── TiDB
    └── YugabyteDB

核心对比

关系型数据库

选型建议：

• 默认选 PostgreSQL：功能最全、扩展性最强、社区最活跃
• MySQL：已有成熟 MySQL 生态、需要简单读写场景
• SQLite：单机、嵌入式、不需要独立服务

文档型数据库

键值数据库

时序数据库

图数据库

向量数据库（AI/ML 场景）

NewSQL

选型决策树

需要事务？
├── 是 → 数据量多大？
│   ├── < 1TB → PostgreSQL / MySQL
│   └── > 1TB → 需要分布式？
│       ├── 是 → CockroachDB / TiDB / YugabyteDB
│       └── 否 → PostgreSQL（读写分离）
├── 否 → 数据模型？
│   ├── 灵活文档 → MongoDB
│   ├── KV 缓存 → Redis
│   ├── 时序数据 → TimescaleDB（已有PG）/ InfluxDB（独立时序）
│   ├── 关系+图 → Neo4j / ArangoDB
│   └── 向量/语义 → Milvus（生产）/ Chroma（原型）

趋势

1. HTAP 混合事务分析：TiDB、CockroachDB 等 NewSQL 正在模糊 OLTP 和 OLAP 的边界
2. 向量数据库爆发：RAG / LLM 应用推动向量数据库需求激增
3. Serverless 数据库：Aurora Serverless、PlanetScale、Neon 等按需计费模式
4. 多模型数据库：ArangoDB、Fauna 等试图用一个引擎覆盖多种数据模型
5. 边缘数据库：SQLite + CRDT（如 LiteFS、Turso）走向边缘部署

参考资料

• PostgreSQL 官方文档
• MongoDB 官方文档
• Redis 官方文档
• Milvus 官方文档
• CockroachDB 官方文档

翻墙客户端

代理客户端本身不提供节点，需要用户自行导入订阅链接或手动配置。客户端的核心差异在于跨平台能力、内核支持、UI 设计和高级功能（如分流规则、TUN 模式等）。

桌面端（Windows / macOS / Linux）

Clash Verge Rev

• GitHub：clash-verge-rev/clash-verge-rev（⭐ 127k）
• 内核：Clash Meta（Mihomo）
• UI：基于 Tauri 框架，体积小、资源占用低，界面现代化
• 特色：支持 TUN 模式、配置文件编辑、订阅管理、规则分流可视化
• 现状：社区活跃度高，更新频繁，桌面端最推荐的客户端之一

Clash Party

• GitHub：mihomo-party-org/clash-party（⭐ 24.8k）
• 内核：Clash Meta（Mihomo）
• UI：基于 Electron，偏向 macOS 风格，交互体验流畅
• 现状：用户群体相对较小

Clash Nyanpasu

• GitHub：libnyanpasu/clash-nyanpasu（⭐ 13k）
• 内核：Clash Meta（Mihomo）
• UI：基于 Tauri，Material You 设计语言，视觉效果精致
• 特色：支持 Clash Meta 和 Clash RS 双内核切换

FlClash

• GitHub：chen08209/FlClash（⭐ 43k）
• 内核：Clash Meta（Mihomo）
• UI：基于 Flutter，一套代码覆盖桌面和移动端
• 适合：希望桌面和手机使用同一款客户端体验的用户

v2rayN

• GitHub：2dust/v2rayN（⭐ 110k）
• 平台：Windows / Linux / macOS
• 内核：支持 Xray、sing-box、v2fly 等多内核
• UI：基于 C# / .NET，Windows 风格
• 特色：支持 VMess、VLESS、Trojan、Shadowsocks、XTLS 等协议，功能全面
• 现状：V2Ray 生态最流行的 GUI 客户端，更新极为频繁

V2rayU

• GitHub：yanue/V2rayU（⭐ 20k）
• 平台：macOS
• 内核：V2Ray Core
• UI：原生 Swift 开发，macOS 风格菜单栏应用
• 特色：支持订阅、二维码导入、剪贴板导入、二维码分享

v2rayA

• GitHub：v2rayA/v2rayA（⭐ 15.2k）
• 平台：Linux
• 内核：支持 Xray-core、sing-box
• UI：Web GUI，通过浏览器访问 http://localhost:2017 管理
• 特色：支持 VMess、VLESS、SS、SSR、Trojan、Tuic、Juicity，适合无桌面环境的 Linux 服务器

Qv2ray

• GitHub：Qv2ray/Qv2ray（⭐ 16.9k）
• 平台：Windows / Linux / macOS
• 内核：V2Ray Core
• UI：C++ / Qt5，插件式架构
• 特色：支持 VMess、VLESS、SSR、Trojan、Trojan-Go、NaiveProxy
• 现状：已归档（archived），不再维护，但仍可使用

Oblivion Desktop

• GitHub：bepass-org/oblivion-desktop（⭐ 8.3k）
• 平台：Windows / macOS / Linux
• 内核：sing-box
• 特色：Cloudflare WARP 非官方客户端，基于 WireGuard 协议，免费可用
• 适合：不想购买机场节点、只需基础翻墙能力的用户

GUI.for.SingBox

• GitHub：GUI-for-Cores/GUI.for.SingBox（⭐ 7.9k）
• 平台：Windows / macOS / Linux
• 内核：sing-box
• UI：Wails（Go）+ Vue 3，轻量现代
• 特色：sing-box 专属 GUI，配置灵活

Throne

• GitHub：throneproj/Throne（⭐ 6.2k）
• 平台：Windows / macOS / Linux
• 内核：sing-box
• UI：C++ 开发，跨平台
• 特色：支持 REALITY、XHTTP、AnyTLS 等最新协议，NekoBox/nekogui 的桌面继承者

Android 端

NekoBox

• GitHub：MatsuriDayo/NekoBoxForAndroid（⭐ 21.5k）
• 内核：sing-box
• 特色：支持 Shadowsocks、VMess、VLESS、Trojan、Hysteria 2、TUIC 等协议，支持 TUN 模式
• 现状：Android 端首选客户端之一，替代了早期的 SagerNet

v2rayNG

• GitHub：2dust/v2rayNG（⭐ 58.4k）
• 内核：Xray-core、v2fly-core
• 特色：支持 VMess、VLESS、Trojan、Shadowsocks、XTLS，功能与 v2rayN 对齐
• 现状：Android 端下载量最大的 V2Ray 客户端

Apple 端（iOS / macOS）

Clash Mi

• 平台：iOS / macOS
• 内核：Clash Meta（Mihomo）
• 特色：基于 Network Extension 框架的原生 Apple 客户端

Shadowrocket（小火箭）

• 平台：iOS / macOS
• 价格：付费（美区 App Store 约 $2.99）
• 特色：iOS 上最老牌的代理客户端，支持 SS、VMess、VLESS、Trojan、Hysteria 2 等，分流规则灵活
• 现状：iOS 端用户量最大的代理客户端

Quantumult X（圈 X）

• 平台：iOS / macOS
• 价格：付费（美区 App Store 约 $7.99）
• 特色：功能最强大的 iOS 代理客户端，支持脚本、重写、MITM、Task 定时任务
• 适合：高级用户，需要去广告、脚本自动化等

Surge

• 平台：iOS / macOS
• 价格：付费（按设备数定价，价格较高）
• 特色：专业级网络调试和代理工具，支持模块化配置、覆写、增强模式
• 适合：开发者、网络工程师

Stash

• 平台：iOS / macOS
• 价格：付费
• 特色：Clash Premium 内核的 Apple 原生客户端，支持 Clash YAML 配置格式

路由器端

OpenClash

• GitHub：vernesong/OpenClash（⭐ 26.4k）
• 平台：OpenWrt 路由器
• 内核：支持 Clash Meta（Mihomo）
• 特色：通过 LuCI Web 界面管理，实现路由器级别的全局翻墙
• 适合：有 OpenWrt 路由器、希望全家设备自动翻墙的用户

全平台（跨端）

Hiddify

• GitHub：hiddify/hiddify-app（⭐ 30.9k）
• 平台：Windows / macOS / Linux / Android / iOS
• 内核：支持 sing-box、Xray、Clash 等多内核
• 特色：自动检测最优协议，内置免费公共配置，界面简洁，对新手友好
• 适合：不想折腾配置、希望开箱即用的用户

客户端对比

TUN 模式

TUN 模式是许多客户端的重要功能。与传统的系统代理（仅接管浏览器等支持代理的应用）不同，TUN 模式通过创建虚拟网卡接管系统所有流量，包括：

• 终端命令行（curl、git、apt 等）
• 不支持代理设置的应用
• UDP 流量（如游戏、视频通话）

注意：TUN 模式通常需要管理员/root 权限。

订阅格式

主流订阅格式有两种：

• Clash 格式：YAML 配置文件，包含代理节点、规则、DNS 等完整配置
• sing-box 格式：JSON 配置，sing-box 生态使用

大多数机场（代理服务商）同时提供两种格式的订阅链接，部分客户端支持自动转换。

开发工具链对比

工具链全景

开发工具链
├── 编辑器 / IDE
├── 版本控制
├── 包管理
├── 构建工具
├── 语言运行时
├── 格式化 / Lint
├── 测试框架
├── CI/CD
├── 容器化
├── API 工具
├── 监控 / APM
└── AI 编程助手

编辑器 / IDE

选型建议：

• 日常开发 → VS Code（生态最全）或 Cursor（AI 增强）
• Java / Kotlin / Go 深度开发 → JetBrains
• 终端重度用户 / 追求速度 → Neovim 或 Zed
• AI-first 体验 → Cursor（最成熟的 AI 编辑器）

版本控制

选型建议：

• 开源项目 → GitHub（社区最大）
• 企业私有部署 → GitLab（自建完整 DevOps 平台）
• 国内合规 → Gitee 或 GitLab 中国版

包管理器

选型建议：

• 新项目 → pnpm（速度快、严格、磁盘省）
• 已有 npm 生态 → npm（兼容性最好）
• 追求极致速度 → bun install

构建工具

选型建议：

• 新前端项目 → Vite（开发体验最好）
• 底层编译需求 → esbuild（Go 编写，极快）
• Next.js → Turbopack（官方默认）
• 复杂 legacy 项目 → Webpack（兼容性最强）

语言运行时

选型建议：

• 生产环境 → Node.js（稳定性、生态最好）
• 全栈应用 → Deno（安全、TypeScript 原生、Deploy 平台）
• 个人项目 / 追求速度 → Bun（启动快、All-in-One）

格式化 / Lint

选型建议：

• JS/TS 项目 → Biome（一个工具替代 Prettier + ESLint，快 10–35 倍）
• Python 项目 → Ruff（替代 Black + isort + flake8，快 10–100 倍）
• 需要复杂 Lint 规则 → ESLint（规则最丰富）

测试框架

选型建议：

• 单元测试 → Vitest（与 Vite 无缝集成，Jest 兼容 API）
• E2E 测试 → Playwright（多浏览器、多语言、速度快）
• 已有 Jest 生态 → Jest（稳定、生态最全）

CI/CD

选型建议：

• GitHub 项目 → GitHub Actions（零配置集成）
• GitLab 自建 → GitLab CI（与 GitLab 深度集成）
• 复杂企业流程 → Jenkins（插件最多、最灵活）

容器化

API 开发工具

选型建议：

• 团队协作 → Postman（功能最全）
• 隐私/开源优先 → Bruno（数据存在本地 Git）
• 轻量级 → Thunder Client（VS Code 内直接用）

监控 / APM

选型建议：

• 预算充足 → Datadog（一站式）
• 成本控制 → Grafana 全家桶（Prometheus + Loki + Tempo，开源免费）
• 错误追踪 → Sentry（前端 + 后端错误聚合）

AI 编程助手

选型建议：

• 日常补全 → GitHub Copilot（集成最好）
• 深度 AI 编码 → Cursor（Agent 模式强大）
• 终端重度用户 → Claude Code（命令行 Agent）
• 自由度最高 → Cline / Continue（可选任意模型）

选型决策

需求？
├── 前端开发 → VS Code/Cursor + Vite + Biome + Vitest + Playwright
├── 后端开发 → VS Code/JetBrains + Node.js/Deno + Docker
├── Python → VS Code + uv + Ruff + Pytest
├── 全栈 → Cursor + Vite + Bun + Docker + GitHub Actions
├── 企业级 → JetBrains + GitLab + Jenkins + Docker + Datadog
└── AI 辅助 → Cursor 或 Claude Code + Copilot

参考资料

• VS Code 官方文档
• JetBrains 官方文档
• Vite 官方文档
• Biome 官方文档
• Ruff 官方文档

前端框架对比

框架全景

前端框架
├── 元框架 (Meta Framework)
│   ├── Next.js (React)
│   ├── Nuxt (Vue)
│   ├── SvelteKit (Svelte)
│   ├── Angular (Angular)
│   └── Remix (React)
├── UI 框架
│   ├── React
│   ├── Vue
│   ├── Svelte
│   ├── Angular
│   └── SolidJS
└── 跨平台
    ├── React Native
    ├── Flutter
    └── Tauri

核心 UI 框架

React

核心理念：

• 组件化：一切皆组件
• 单向数据流：Props 向下，Events 向上
• 声明式：描述 “是什么”，不是 “怎么做”

代码示例：

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(c => c + 1)}>
      Count: {count}
    </button>
  );
}

Vue

核心理念：

• 渐进式：可以从 CDN 引入，也可以用完整构建工具链
• 双向数据流：v-model 简化表单绑定
• 组合式 API：Vue 3 Composition API 对标 React Hooks

代码示例：

<script setup>
import { ref } from 'vue';
const count = ref(0);
</script>

<template>
  <button @click="count++">Count: {{ count }}</button>
</template>

Svelte

核心理念：

• 编译时框架：构建时将组件编译为原生 DOM 操作
• 无运行时：无虚拟 DOM、无 diff 算法开销
• 代码即框架：框架在编译时消失

代码示例：

<script>
  let count = $state(0);
</script>

<button onclick={() => count++}>Count: {count}</button>

Angular

核心理念：

• 全家桶：框架内置路由、表单、HTTP、测试
• 依赖注入：一等公民
• TypeScript 优先：类型安全是强制的

代码示例：

@Component({
  selector: 'app-counter',
  template: `<button (click)="count++">Count: {{ count }}</button>`
})
export class CounterComponent {
  count = 0;
}

SolidJS

核心理念：

• React 语法 + 真实 DOM：像 React 写，但不走 diff
• 细粒度更新：信号（Signal）级别的精确更新
• 无重渲染：组件函数只执行一次

元框架 (Meta Framework)

选型建议：

• React 生态 → Next.js（最大、最多部署支持）
• Vue 生态 → Nuxt（Vue 官方推荐）
• 追求性能 → SvelteKit（编译时优势）
• 侧重服务端逻辑 → Remix（Web 标准优先）

状态管理方案

React 生态

Vue 生态

Svelte 生态

CSS 方案

选型建议：

• 新项目 → Tailwind CSS（行业标准、生态最全）
• 需要类型安全 → Panda CSS 或 Vanilla Extract
• 追求极致性能 → UnoCSS（引擎级，比 Tailwind 快）

性能对比

Bundle Size（框架核心）

渲染性能（基准测试）

Svelte > Solid > Vue 3 > React > Angular
   ↑                      ↑         ↑
 编译时           虚拟DOM(优化)    变更检测

注意：实际应用性能差异远小于基准测试，框架选择对 99% 的应用不是性能瓶颈。

选型决策

场景？
├── 已有 React 经验 → Next.js（元框架）+ Zustand + Tailwind
├── 已有 Vue 经验 → Nuxt（元框架）+ Pinia + Tailwind
├── 追求极致性能 → SvelteKit + Tailwind
├── 企业级大型应用 → Angular + NgRx + Angular Material
├── 跨平台移动 → React Native 或 Flutter
├── 不确定 → Next.js（生态最大、招聘最容易）
└── 个人项目 → SvelteKit（开发体验最好）

按团队规模

新兴趋势

1. Server Components：Next.js App Router、React Server Components 将渲染推向服务端，减少客户端 JS
2. Signals：Angular 19+ Signals、Svelte 5 Runes、SolidJS Signals — 细粒度响应式成为主流
3. 编译时优化：Svelte、SolidJS 证明编译时可以大幅减少运行时开销
4. 边缘优先：Cloudflare Workers、Vercel Edge 让 SSR 推到 CDN 边缘
5. AI 辅助开发：v0.dev (Vercel)、Bolt.new 等 AI 生成 UI 工具兴起

参考资料

• React 官方文档
• Vue 官方文档
• Svelte 官方文档
• Angular 官方文档
• Next.js 官方文档
• Nuxt 官方文档
• SvelteKit 官方文档

Gartner 曲线：所有“改变世界”的技术，都逃不过这条曲线

在科技行业，几乎每隔几年，就会出现一种“即将改变世界”的新技术。 从互联网、区块链、元宇宙，到今天的大模型与 AI Agent，人们总会经历一轮相似的情绪周期：

最开始是兴奋与狂热，随后是失望与质疑，最后才逐渐回归现实，找到真正有价值的落地方向。

而这种现象，正是著名咨询机构 Gartner 提出的 Gartner Hype Cycle（技术成熟度曲线） 所描述的内容。

什么是 Gartner 曲线？

Gartner 曲线，又被称为“技术炒作周期”，是一种用于分析新技术发展规律的模型。

它并不直接衡量技术本身的先进程度，而是描述：

市场、媒体、资本以及公众，对一项新技术的“期待值变化”。

这条曲线通常分为五个阶段。

1. 技术萌芽期（Innovation Trigger）

这是技术刚刚出现的时候。

通常只有少量研究人员、创业公司或极客群体在关注它。 技术可能还不成熟，产品体验也并不完善，但它展示出了巨大的潜力。

例如：

• 早期的区块链
• 2012 年前后的深度学习
• 刚出现时的 GPT 模型

在这个阶段，人们会开始讨论：

• “它未来会不会改变行业？”
• “是不是下一次技术革命？”

虽然商业价值尚未验证，但想象空间已经被打开。

2. 期望膨胀期（Peak of Inflated Expectations）

随后，技术开始爆红。

媒体大量报道，资本疯狂进入，创业公司迅速增长。 很多人会相信：

“它将彻底颠覆一切。”

这时最典型的现象包括：

• PPT 多于真实产品
• 概念多于实际价值
• 估值远高于盈利能力

例如：

• 元宇宙热潮时期
• NFT 爆发阶段
• ChatGPT 刚发布后的 AI 狂热

在这个阶段，市场往往会出现严重的“过度预期”。

3. 幻灭低谷期（Trough of Disillusionment）

当现实无法满足过高期待时，泡沫开始破裂。

大量项目失败，用户流失，投资退潮。 公众态度会从：

“它将改变世界”

迅速转变为：

“这东西根本没用。”

这是 Gartner 曲线中最容易被误判的阶段。

因为很多真正伟大的技术，并不是死在技术问题上，而是死在：

• 过早商业化
• 不成熟的生态
• 错误的市场预期

例如：

• VR 曾长期陷入低谷
• 区块链在多轮周期中经历崩盘
• 自动驾驶多次遭遇“过度承诺”

4. 启蒙爬坡期（Slope of Enlightenment）

经历低谷后，行业开始冷静下来。

真正有价值的应用场景逐渐被发现，技术路线开始成熟，企业也开始关注：

• 成本
• 效率
• 稳定性
• 商业闭环

这个阶段的重要特点是：

“从讲故事，转向解决问题。”

例如今天的大模型行业，已经开始从“AI 能做什么”，转向：

• AI 如何真正提高生产力
• 如何降低推理成本
• 如何构建 Agent 工作流
• 如何实现长期商业化

5. 生产力平台期（Plateau of Productivity）

最终，技术真正融入社会基础设施。

它不再被当成“未来科技”，而是变成普通工具。 人们甚至不会再特别讨论它。

例如：

• 云计算
• 搜索引擎
• 智能手机
• 移动支付

今天很少有人会说：

“互联网将改变世界。”

因为互联网已经成为世界本身的一部分。

为什么 Gartner 曲线重要？

Gartner 曲线最大的价值，在于它提醒人们：

技术的发展，并不是线性的。

市场情绪经常会：

• 高估短期影响
• 低估长期价值

很多技术在最火的时候并不成熟， 而真正创造长期价值的时候，反而已经没人关注。

因此，无论是投资者、创业者，还是普通用户，都可以通过 Gartner 曲线更理性地理解：

• 为什么技术会突然爆火
• 为什么泡沫一定会出现
• 为什么“低谷期”反而可能孕育真正机会

AI 正处于 Gartner 曲线的哪个阶段？

这是当前最热门的问题之一。

不同人有不同判断，但整体来看：

• 基础大模型仍处于“期望膨胀期”向“幻灭低谷期”过渡
• AI Agent、AI Coding、AI 搜索等细分领域，已经开始进入“启蒙爬坡期”

真正的长期赢家，很可能并不是最会营销的公司，而是：

• 能持续降低成本
• 能真正提升效率
• 能形成稳定生态
• 能进入真实工作流

的那一批企业。

结语

Gartner 曲线本质上并不是在描述技术。

它描述的是：

人类面对新技术时，反复循环的情绪模式。

每一次技术革命，都会经历：

• 狂热
• 泡沫
• 失望
• 重建
• 普及

而真正改变世界的，往往不是“最火”的技术， 而是那些穿越泡沫之后，依然能够解决现实问题的技术。

SQL标准

SQL标准自1986年诞生以来，一直由**ISO（国际标准化组织）和ANSI（美国国家标准协会）**共同维护。它的演进并非简单的版本更迭，而是伴随着数据库技术的发展，不断融入新特性以满足时代需求。

以下是SQL标准的主要版本及其关键特性：

📜 SQL标准演进时间线

🔍 关键演进细节与趋势

1. 标准符合度的定义变化 早期的SQL-92标准将兼容性划分为“入门级”、“中级”和“完全级”三个递进层次。但从SQL:1999开始，标准不再使用这种粗粒度的分级，而是定义了一组庞大的、独立的“核心功能”和众多“可选功能”。一个数据库系统只要实现了所有“核心功能”，并支持一部分“可选功能”，即可称其符合标准。

2. 应对新兴数据需求的演进 标准的演进清晰地反映了技术趋势：从2000年代对XML的支持，到2010年代对时序数据的关注，再到2016年起全面拥抱JSON，以及最新版对图数据的支持。这标志着SQL正在从单纯的结构化数据管理工具，演变为能够处理多样化数据模型的通用语言。

3. 实际应用中的“方言”现象 尽管有统一标准，但不同的数据库产品（如Oracle的PL/SQL、SQL Server的T-SQL、PostgreSQL的PL/pgSQL）都会在标准基础上进行扩展，形成自己的“方言”。因此，在实际工作中，理解标准是基础，但熟悉具体数据库的“方言”同样重要。

目前主流的数据库，如 PostgreSQL、GaussDB 等，都已支持SQL:2016甚至SQL:2023的大部分核心功能。对于大多数开发者而言，掌握 SQL-92 的核心语法和 SQL:2003 引入的窗口函数，就足以应对绝大多数日常的数据处理需求。

如果你正在使用某一款具体的数据库（如 MySQL、PostgreSQL、Oracle 等），想了解它对特定 SQL 标准版本的支持情况，可以随时告诉我，我来帮你进一步分析。

谷歌、微软、苹果的设计语言

Google — Material Design

起源与演进

核心理念

• 纸墨隐喻：界面元素是有高度（elevation）的纸片，通过阴影表达层级
• 运动即沟通：转场动画（shared element transition）不是装饰，是导航线索
• 响应式：同一套规范覆盖手机、平板、桌面、可穿戴、车载

视觉特征

• 强调 颜色系统：primary / secondary / tertiary / surface / error 五大色阶
• 圆角随版本递增（MD2: 4dp → MD3: 16–28dp）
• 大量使用 FAB（Floating Action Button）作为核心操作锚点
• Typography Scale 使用 13 级 type scale（Display → Label）

设计工具

• Material Theme Builder
• Figma UI Kit（官方维护）
• material-web — Web Components 实现

Microsoft — Fluent Design System

起源与演进

核心理念

• 五要素：光（Light）、深度（Depth）、运动（Motion）、材质（Material）、缩放（Scale）
• 系统优先：为 Microsoft 365（Teams、Outlook、Edge、Windows）的庞大生态服务
• 无障碍：从第一天就内建 WCAG 2.1 AA 合规

视觉特征

• 中性、克制：大面积留白，强调信息密度而非视觉冲击
• 圆角：MD 4–8px（保守），突出专业感
• Dark Mode 是一等公民，不是附加
• 大量使用 Persona（人头像 + 名字）在协作场景

设计工具

• Fluent UI 官方文档
• Figma Fluent UI Kit（官方）
• react-components — React 实现

Apple — Human Interface Guidelines (HIG)

起源与演进

核心理念

• 内容优先：UI 是内容的容器，不是主角
• 一致性 > 新颖性：跨平台体验要让用户感觉 “这是同一个 app”
• 直接操控：多点触控、手势是自然交互，不是快捷方式

视觉特征

• SF Pro / SF Rounded / SF Compact：三种字体变体，可变字重
• 配色：不强调主色调，而是依赖系统语义色（label, separator, systemGray）
• 圆角：统一使用 continuous corner（squircle），比普通圆角更自然
• 毛玻璃（vibrancy / material blur）是标志性视觉语言
• 大量使用 SF Symbols（5000+ 矢量图标，4 权重自适应）

设计工具

• HIG 官方文档
• Apple Design Resources（Figma / Sketch）
• SF Symbols App

三者对比

关键趋势

1. Token 化：三者都已将颜色、间距、圆角抽象为 design tokens，支持跨平台同步
2. Dark Mode 一等公民：不再是附加功能，从第一天就内建
3. 无障碍：WCAG 2.1 AA 成为底线要求，高对比度模式被纳入核心
4. AI 可适应性：Microsoft 已开始探索 Copilot 风格的 AI-first 界面；Material You 的 dynamic color 本身就是个性化的雏形
5. 空间计算：Apple 的 visionOS HIG 是目前唯一系统的空间 UI 规范

参考资料

• Material Design 3 官方文档
• Fluent UI 官方文档
• Apple Human Interface Guidelines

手机作为 IPv6服务器

tags: [网络, IPv6, 服务器, 手机, Android]

手机作为 IPv6服务器

概要

利用手机的移动网络（4G/5G）天然拥有公网 IPv6 地址的特性，将手机变成一台轻量级服务器，无需内网穿透、无需公网 IPv4，即可对外提供服务。

原理

为什么手机有公网 IPv6？

• 中国三大运营商（移动/联通/电信）在 4G/5G 网络中已全面部署 IPv6
• 每张 SIM 卡分配的 IPv6 地址通常是全球单播地址（2400:/2001: 开头），而非 NAT 后的地址
• 这意味着手机直接暴露在公网上（仅 IPv6），任何 IPv6 网络均可直接访问

与家庭宽带的对比

前置条件

1. SIM 卡：开通了 IPv6 的手机卡（目前三大运营商默认已支持）
2. 手机系统：Android 推荐（可 root 更佳），iOS 因系统限制功能有限
3. 确认 IPv6 可用：浏览器访问 ipv6.test-ipv6.com 确认获得公网 IPv6 地址
4. 目标访问端：访问方也需要 IPv6 网络（家庭宽带 + 光猫开启 IPv6，或手机流量）

方案一：Termux + SSH（最基础）

安装 Termux

从 F-Droid 下载安装 Termux（不要用 Play Store 版本，已过时）。

配置 SSH 服务

# 安装 openssh
pkg update && pkg install openssh

# 设置密码
passwd

# 启动 sshd（默认监听 8022 端口）
sshd

获取 IPv6 地址

# 查看手机的 IPv6 地址
ifconfig
# 或
ip -6 addr show

找到 rmnet_data0（移动数据接口）上的 scope global 地址，类似 2408:xxxx:xxxx::xxxx。

从外部连接

ssh -p 8022 user@[2408:xxxx:xxxx::xxxx]

注意：方括号是 IPv6 地址的必需格式。

方案二：Termux + Web 服务器

Nginx

pkg install nginx

# 编辑配置，监听 IPv6
nano $PREFIX/etc/nginx/nginx.conf

确保 listen 指令包含：

listen [::]:8080;

启动：

nginx

Python HTTP Server

# Python 内置，零依赖
python3 -m http.server 8080 --bind ::

Node.js

pkg install nodejs

创建 server.js：

const http = require('http');
const server = http.createServer((req, res) => {
  res.writeHead(200, {'Content-Type': 'text/html'});
  res.end('<h1>Hello from phone!</h1>');
});
server.listen(8080, '::', () => {
  console.log('Server running on [::]:8080');
});

node server.js

方案三：运行各类服务

在 Termux 中可以运行几乎所有 Linux 服务：

# 文件服务器（FTP/SFTP 已包含在 SSH 中，scp 即可传输）

# 数据库
pkg install mariadb
mariadb-install-db
mysqld_safe &

# Git 服务器（通过 SSH 即可，Git 原生支持 SSH 协议）
# 在手机上创建 bare repo
mkdir ~/git/myrepo.git && cd ~/git/myrepo.git
git init --bare
# 外部通过 git clone ssh://[2408:xxxx::xxxx]:8022/~/git/myrepo.git 克隆

稳定性与注意事项

IP 地址变化问题

手机 IPv6 地址可能因以下原因变化：

• 切换基站（移动中）
• 飞行模式开关
• 重启手机
• 运营商重新分配前缀

解决方案：

• DDNS：使用支持 IPv6 的 DDNS 服务（如 Cloudflare API），配合定时脚本更新 DNS 记录
• 临时方案：适用于一次性使用、开发调试、临时文件传输等场景

防火墙

• Android 系统本身没有入站防火墙（非 root 情况下），Termux 的服务默认可被外部访问
• 部分运营商可能对入站流量做了过滤（尤其是常用端口如 80/443），建议使用高位端口（如 8080、8443）
• 如需精细控制，root 后可使用 iptables / ip6tables

电量与性能

• 长时间运行服务会消耗电量，建议连接充电器
• Termux 在后台可能被系统杀死，可使用 termux-wake-lock 保持唤醒：

  termux-wake-lock
  

• MIUI/ColorOS/OneUI 等深度定制系统需要在设置中关闭 Termux 的电池优化

安全建议

• 必须设置强密码或使用 SSH 密钥认证
• 不要暴露不必要的端口
• 考虑使用 fail2ban 防暴力破解（需 proot 完整 Linux 环境）
• 定期检查开放端口：ss -tlnp

进阶：proot 完整 Linux 环境

如果 Termux 原生环境不够用，可以通过 proot-distro 安装完整 Linux 发行版：

pkg install proot-distro
proot-distro install debian
proot-distro login debian

# 在 Debian 环境中可以安装完整的 nginx、docker（部分）、systemd 服务等
apt update && apt install nginx

典型使用场景

参考资料

• Termux 官方文档
• 中国运营商 IPv6 部署现状
• Android IPv6 配置

翻墙协议的演进

翻墙协议的演进，本质上是一场加密与流量识别技术持续对抗的缩影。其核心路径可以概括为：从简单的代理转发，演进到加密隧道，再升级为深度协议伪装，并最终分化为追求极致隐蔽与极致速度的两条路线。

以下是这一演进过程的关键阶段与代表性技术：

📡 第一阶段：早期隧道与简单代理 (1990s - 2000s)

这一时期的工具主要用于绕过基础的IP封锁，几乎没有有效的加密或流量伪装能力，在现代深度包检测（DPI）技术面前很容易被识别和封锁。

• HTTP代理：工作原理类似于一个简单的“请求转发者”，流量特征极为明显，内容几乎是“半裸奔”状态，是最早被淘汰的方案。
• PPTP (点对点隧道协议)：由微软于1996年推出，是首个广泛应用的VPN协议，极大推动了VPN的实用化。但其加密级别低，存在已知安全漏洞，早已被视为不安全协议。
• L2TP/IPsec (二层隧道协议)：由微软和思科共同开发，结合了L2TP的隧道功能和IPsec的加密机制。它比PPTP更安全，但由于采用“双重封装”，速度较慢，且协议特征仍可被识别。

🔒 第二阶段：加密与分流时代 (2012-2017)

这一阶段的革命性在于引入了自定义加密和“智能分流”机制，极大地提升了性能和隐蔽性。

• Shadowsocks (SS)：这是一个里程碑式的协议。它不再使用标准协议，而是采用自定义的轻量级加密，将流量“伪装”成看似无特征的随机数据，并首次实现智能分流（国内流量直连，国外流量走代理），解决了传统VPN的卡顿问题。
• ShadowsocksR (SSR)：SS的一个分支，增加了更多混淆参数，红极一时，但后来因开发停止而逐渐淡出。

🎭 第三阶段：深度伪装时代 (2018-2022)

当防火墙开始能够识别“随机流量”特征后，协议演进的核心思路变为“将自己伪装成最常见的HTTPS正常流量”。

• VMess：V2Ray的核心协议，设计复杂，通过动态端口、时间戳验证等方式增加识别难度，但其“TLS in TLS”的特征后被针对。
• Trojan：理念“大道至简”，通过完成完整的TLS握手，将代理流量伪装成一个完全正常的HTTPS网站。若探测到非代理请求，服务器会返回一个真实的网页，隐蔽性极强。
• VLESS：VMess的简化版，将加密工作完全剥离给外层的TLS（传输层安全协议），协议本身极其轻量，为后续的演进打下基础。

⚡️ 第四阶段：速度与极限伪装 (2021-至今)

此阶段开始分化出两条路线：一条是追求极致速度的UDP（用户数据报协议）/QUIC（快速UDP网络连接）路线，另一条是将伪装做到极致的“盗用”路线。

• 极致速度 (UDP系)：

  • Hysteria：基于QUIC协议，通过“暴力发包”和内置的拥塞控制，能在极差的网络环境（如高丢包率）下实现逆天速度，尤其适合看视频和玩游戏。但其激进的发包行为在高峰期可能被运营商QoS（服务质量）限速。

• 极限伪装 (TCP系)：

  • REALITY：当前最强的伪装技术之一。它不再需要自己的域名和证书，而是“盗用”如微软、苹果等真实大网站的TLS指纹。这使得防火墙几乎无法主动探测，因为其流量与正常访问这些大网站一模一样。
  • NaiveProxy：直接使用Chrome浏览器的网络堆栈，使得网络流量特征与浏览器100%一致，在白名单模式下被认为是极难被封锁的方案。

📊 演进路线图对比

🚀 未来趋势

翻墙技术的演进并未停止。未来的对抗可能会集中在以下几个方向：

1. AI驱动的动态对抗：防火墙可能会引入AI模型，通过分析流量的行为特征（如时间模式、数据包大小分布）而非单纯的协议指纹来识别代理流量。
2. 量子安全加密：随着量子计算的发展，现有的加密算法（如RSA、AES）面临被破解的风险。未来协议需要集成后量子密码学（PQC）算法以应对长远威胁。
3. 架构的“隐形化”：如SASE（安全访问服务边缘）架构的兴起，将网络与安全功能融合为云服务，使得代理技术成为底层基础设施的一部分，对最终用户更加透明。