✨📒

详细记录一下此次建站过程

开始

之前的博客是基于jekyll打造的，要添加和定制化的东西都只能基于html+js+css完成，有些麻烦，所以一直有想更换引擎的想法
直到偶然间发现vuepress，首先是被vue3+typescript+vite吸引，然后看到默认主题属实有点不合符我的期待，自己动手成本又太高，也没有太急着去折腾，直到无意中发现了
vuepress-theme-hope，漂亮的外观一下子就吸引到我了，然后去官网深入研究了一番，发现二次开发的成本并不高，对于我来说比较友好，基本都是基于选项的配置型，和一小部分的定制开发，也可以基于vue来写，这让我觉得很合适。所以，一步步折腾了起来……

近期更新

Changelog

2026-07-01 e1a2760 - 新增音乐页

• 新增独立 /music/ 音乐页面，基于自定义 Music.vue 布局，配置导航栏入口与主题路由。
• 重构布局 CSS，将 _base.scss 拆分为 _buttons.scss、_layout.scss 等独立模块，提升样式可维护性。
• 修复 banner-button 按钮样式，精简 About 和 Essay 页面冗余代码。
• 优化 About、Essay、Link 布局样式细节与动画配置。

2026-06-30 61885d4 - 移除 pages.css，SCSS 模块化迁移

• 移除 5000+ 行的第三方 pages.css，将样式迁移至 SCSS 模块（_animations.scss、_base.scss、_variables.scss、_skills-tags.scss）。
• About、Essay、Link 布局组件内联对应样式，减少全局 CSS 依赖。
• 删除重复样式内容，修复样式错乱问题。
• 更新 .gitignore 配置。

2026-06-29 f636cd3 - 双栏布局 tag 样式与时间轴修复

• 优化双栏文章列表 tag 样式展示。
• 新增 TimelineItems.vue 自定义组件，修复时间轴页面渲染问题。

2026-06-29 f38ac1f - 新增友链页布局

• 新增独立 /link/ 友链页面，迁移原 friend.md 内容到新的 Link layout。
• 抽离友链数据到 src/.vuepress/data/link.ts，统一维护站点信息、分组、申请说明与免责声明。
• 引入 AnZhiYu 风格的友链横幅、头像滚动、站点卡片和申请入口，并接入主题路由与导航。

2026-06-29 692ab4d - 重构关于页与即刻页

• 关于我迁移为独立 /about/ 页面，基于 AnZhiYu 风格重做卡片布局、动效与个人信息数据源。
• 新增 /essay/ 即刻布局与数据配置，替换原 news 说说列表实现。
• 补充相关静态资源、AnZhiYu 样式、评论背景、地图与站点 Logo 资源，同时保留关于本站为 /about-site/。

2026-06-26 64a093 - 文章列表支持双栏

• 首页文章列表新增 single / double 两种展示模式，可在主题配置中切换阅读密度。
• 自定义 ArticleList 与 ArticleItem，重排封面、标题、分类、标签和日期信息。
• 为双栏卡片补充响应式样式，移动端自动回落为单栏展示。

Markdown增强

hope主题的markdown效果是出乎意料的好，而且支持了很多普通markdown不支持的东西，如自定义容器、带tab的代码块，最方便的是可以直接写流程图了，可选高亮主题（本站代码高亮基于shikiPlugin,虽不如默认的prismjs轻量高效，但能提供更准确的语法高亮）具体效果看这里☞Markdown展示

目录结构

.
├── .github
│   ├── ISSUE_TEMPLATE # issus 模版
│   │   └── bug-report.yml
│   └── workflows
│       └── deploy-docs.yml # 推送脚本
├── CNAME
├── LICENSE
├── README.md
├── api
│   └── proxy.js # 跨域代理
├── env.d.ts
├── package.json
├── pnpm-lock.yaml
├── script
│   ├── requirements.txt 
│   └── submit.py # Github Actions 推送URL使用脚本
├── src
│   ├── .vuepress
│   │   ├── client.ts # 客户端配置文件
│   │   ├── components
│   │   │   ├── MyCoverLink.vue # 友链组件
│   │   │   └── Mylink.vue # 卡片组件
│   │   ├── config.ts # vuepress配置文件
│   │   ├── data # 数据
│   │   ├── navbar
│   │   ├── plugins
│   │   │   ├── vuepress-plugin-canvas
│   │   │   ├── vuepress-plugin-gradient-cover
│   │   │   ├── vuepress-plugin-hitokoto
│   │   │   ├── vuepress-plugin-live2DAssist
│   │   │   └── vuepress-plugin-popper
│   │   ├── public
│   │   │   ├── assets # 资源
│   │   ├── sidebar
│   │   ├── styles
│   │   ├── theme
│   │   │   ├── api
│   │   │   │   └── bing.ts # bing 每日壁纸
│   │   │   ├── components #自定义组件
│   │   │   ├── index.ts
│   │   │   ├── layouts # 自定义布局
│   │   │   └── utils
│   │   │       ├── busuanzi.pure.js # 不蒜子统计
│   │   │       └── time.ts #运行时间
│   │   └── theme.ts # 主题配置文件
│   └── README.md
├── tsconfig.json
└── vercel.json # vercel 配置文件

框架支持

vuepress2.x

主题支持

vuepress-theme-hope

自定义内容

基于原主题进行了继承，个性化内容如下，主要自定义内容分为

1. 自定义布局

   • NotFound.vue
   • Layout.vue(增加打赏组件)
   • About.vue（关于我页面）
   • Essay.vue（即刻列表布局）
   • Link.vue（友链页面）

2. 自定义组件

   • BlogHero.vue
   • ArticleList.vue（文章列表）
   • ArticleItem.vue（文章卡片）
   • PageFooter.vue
   • Sponsor.vue（打赏组件）

3. 本地插件开发

   • vuepress-plugin-canvas（支持彩虹背景和动态几何图形两种）
   • vuepress-plugin-gradient-cover （遮罩背景）
   • vuepress-plugin-hitokoto （一言插件）
   • vuepress-plugin-live2DAssist （看板娘辅助，由于子页有sidebar，看板娘会挡住，所以写了一个子页隐藏的小东西）
   • vuepress-plugin-popper （鼠标特效，基于@moefy-canvas/theme-popper）

4. 引用外部内容

   • vuepress-plugin-oh-my-live2d 看板娘插件

   • 不蒜子统计

   • @moefy-canvas/theme-popper原有插件只支持vuepress1.x，自己基于moefy-canvas进行了支持vuepress2.x的本地化插件开发

   • @vuepress/plugin-google-analytics 支持Google Analytics 4 正好看到通知原来的UA也要被强制转换了，所以更换了G4

5. 配置内容

   • navbar
   • sidebar
   • 评论基于 Waline
   • 搜索基于algolia
   • 启用 copyright 版权信息插件
   • feed rss插件
   • 增加文章类型-即刻，为即刻 markdown 图片添加预览选择器
   • 友链页数据配置，统一维护站点分组、申请模板与免责声明
   • 文章列表布局配置，支持 single / double 两种展示模式

6. 零碎

   • 运行时间统计
   • CSS 样式美化
   • 引入字体，品如手写体，夏行楷体
   • wanlie 增加自定义emoji，并修改展示样式
   • 个性log
   • 自动推送新文章url到搜索引擎（百度、Bing、Google）👉详细配置

总结

未完待续，持续优化中

本地插件，喜欢自取，源码公开，点击右上角，github图标即可，当然不要忘记点个✨哦

页面标题

The first H1 title in Markdown will be regarded as page title.

Markdown 中的第一个 H1 标题会被视为页面标题。

你可以在 Markdown 的 Frontmatter 中设置页面标题。

页面标题

The first H1 title in Markdown will be regarded as page title.

Markdown 中的第一个 H1 标题会被视为页面标题。

你可以在 Markdown 的 Frontmatter 中设置页面标题。

页面标题

The first H1 title in Markdown will be regarded as page title.

Markdown 中的第一个 H1 标题会被视为页面标题。

你可以在 Markdown 的 Frontmatter 中设置页面标题。

页面标题

The first H1 title in Markdown will be regarded as page title.

Markdown 中的第一个 H1 标题会被视为页面标题。

你可以在 Markdown 的 Frontmatter 中设置页面标题。

页面标题

The first H1 title in Markdown will be regarded as page title.

Markdown 中的第一个 H1 标题会被视为页面标题。

你可以在 Markdown 的 Frontmatter 中设置页面标题。

页面标题

The first H1 title in Markdown will be regarded as page title.

Markdown 中的第一个 H1 标题会被视为页面标题。

你可以在 Markdown 的 Frontmatter 中设置页面标题。

学习目录

一、Web3 基础与行业全景

理解 Web3、区块链、公链、钱包、DeFi、稳定币、NFT、GameFi、DAO、监管、行业机会与资产安全。

二、账户、钱包与链上操作

完成交易所、钱包、区块浏览器、跨链桥与 DEX 等基础工具的准备，并建立安全操作习惯。

三、项目研究与估值框架

学习赛道分类、公链估值、项目调研、长期标的分析，以及一级和二级市场的基本研究方法。

四、链上数据与情报分析

掌握链上数据、信息流、Gas、地址分析、巨鲸监控和数据看板等常用研究方法。

五、加密货币交易实践

通过 Binance、Bitget 等中心化交易所，学习现货、永续合约、订单类型、仓位管理与交易复盘。

六、链上美股与全球资产交易

区分真实股票、代币化股票和美股合约，理解链上交易机制、产品权益以及平台与监管风险。

你应该创建和编写 Markdown 文件，以便 VuePress 可以根据文件结构将它们转换为不同的页面。

Markdown 介绍

如果你是一个新手，还不会编写 Markdown，请先阅读 Markdown 介绍 和 Markdown 演示。

Markdown 配置

VuePress 通过 Frontmatter 为每个 Markdown 页面引入配置。

Markdown 扩展

VuePress 会使用 markdown-it 来解析 Markdown 内容，因此可以借助于 markdown-it 插件来实现 语法扩展 。

VuePress 扩展

为了丰富文档写作，VuePress 对 Markdown 语法进行了扩展。

关于这些扩展，请阅读 VuePress 中的 Markdown 扩展。

主题扩展

通过 [vuepress-plugin-md-enhance][md-enhance]，主题扩展了更多 Markdown 语法，提供更加丰富的写作功能。

自定义容器

const a = 1;

• 查看详情

代码块

• 查看详情

上下角标

19^th H₂O

• 查看详情

自定义对齐

• 查看详情

Attrs

一个拥有 ID 的 单词。

• 查看详情

脚注

此文字有脚注^[1].

• 查看详情

标记

你可以标记 重要的内容 。

• 查看详情

任务列表

• 计划 1

• 计划 2

• 查看详情

图片增强

支持为图片设置颜色模式和大小

• 查看详情

图表

::: chart 一个散点图案例

{
  "type": "scatter",
  "data": {
    "datasets": [
      {
        "label": "散点数据集",
        "data": [
          { "x": -10, "y": 0 },
          { "x": 0, "y": 10 },
          { "x": 10, "y": 5 },
          { "x": 0.5, "y": 5.5 }
        ],
        "backgroundColor": "rgb(255, 99, 132)"
      }
    ]
  },
  "options": {
    "scales": {
      "x": {
        "type": "linear",
        "position": "bottom"
      }
    }
  }
}

:::

• 查看详情

Echarts

• 查看详情

流程图

• 查看详情

Mermaid

页面标题

The first H1 title in Markdown will be regarded as page title.

Markdown 中的第一个 H1 标题会被视为页面标题。

你可以在 Markdown 的 Frontmatter 中设置页面标题。

页面标题

The first H1 title in Markdown will be regarded as page title.

Markdown 中的第一个 H1 标题会被视为页面标题。

你可以在 Markdown 的 Frontmatter 中设置页面标题。

页面标题

The first H1 title in Markdown will be regarded as page title.

Markdown 中的第一个 H1 标题会被视为页面标题。

你可以在 Markdown 的 Frontmatter 中设置页面标题。

本页面就是一个示例，禁用了如下功能:

• 导航栏
• 侧边栏
• 路径导航
• 页面信息
• 贡献者
• 编辑此页链接
• 更新时间
• 上一篇/下一篇 链接
• 评论
• 页脚
• 返回顶部按钮

段落 1 文字段落 1 文字段落 1 文字段落 1 文字段落 1 文字段落 1 文字段落 1 文字段落 1 文字段落 1 文字段落 1 文字段落 1 文字段落 1 文字。

段落 2 文字段落 2 文字段落 2 文字段落 2 文字段落 2 文字段落 2 文字段落 2 文字段落 2 文字段落 2 文字段落 2 文字段落 2 文字段落 2 文字段落 2 文字段落 2 文字。

• 导航栏
• 侧边栏
• 页脚

同时每个页面包含:

• 路径导航
• 标题和页面信息
• TOC (文章标题列表)
• 贡献者、更新时间等页面元信息
• 评论

主题也带有以下元素:

• 夜间模式按钮
• 返回顶部按钮
• 打印按钮

你可以在主题选项和页面的 frontmatter 中自定义它们。

你应该创建和编写 Markdown 文件，以便 VuePress 可以根据文件结构将它们转换为不同的页面。

Markdown 介绍

如果你是一个新手，还不会编写 Markdown，请先阅读 Markdown 介绍 和 Markdown 演示。

Markdown 配置

VuePress 通过 Frontmatter 为每个 Markdown 页面引入配置。

Markdown 扩展

VuePress 会使用 markdown-it 来解析 Markdown 内容，因此可以借助于 markdown-it 插件来实现 语法扩展 。

VuePress 扩展

为了丰富文档写作，VuePress 对 Markdown 语法进行了扩展。

关于这些扩展，请阅读 VuePress 中的 Markdown 扩展。

主题扩展

通过 vuepress-plugin-md-enhance，主题扩展了更多 Markdown 语法，提供更加丰富的写作功能。

提示容器

const a = 1;

• 查看详情

代码块

• 查看详情

上下角标

19^th H₂O

• 查看详情

自定义对齐

• 查看详情

Attrs

一个拥有 ID 的 单词。

• 查看详情

脚注

此文字有脚注^[1].

• 查看详情

标记

你可以标记 重要的内容 。

• 查看详情

任务列表

• 计划 1

• 计划 2

• 查看详情

图片增强

支持为图片设置颜色模式和大小

• 查看详情

组件

title: Mr.Hope
desc: Where there is light, there is hope
logo: https://mister-hope.com/logo.svg
link: https://mister-hope.com
background: rgba(253, 230, 138, 0.15)

• 查看详情

导入文件

• 查看详情

样式化

向 Mr.Hope 捐赠一杯咖啡。

• 查看详情

Tex 语法

$$\frac {\partial^r} {\partial \omega^r} \left(\frac {y^{\omega}} {\omega}\right) = \left(\frac {y^{\omega}} {\omega}\right) \left\{(\log y)^r + \sum_{i=1}^r \frac {(-1)^i r \cdots (r-i+1) (\log y)^{r-i}} {\omega^i} \right\}$$

• 查看详情

图表

• 查看详情

Echarts

• 查看详情

流程图

• 查看详情

MarkMap

• 查看详情

Mermaid

• 查看详情

代码演示

• 查看详情

交互演示

• 查看详情

Kotlin 交互演示

• View Detail

Vue 交互演示

• 查看详情

Sandpack 交互演示

• 查看详情

幻灯片

• 查看详情

页面标题

The first H1 title in Markdown will be regarded as page title.

Markdown 中的第一个 H1 标题会被视为页面标题。

你可以在 Markdown 的 Frontmatter 中设置页面标题。

站点板块

首页

返回网站首页，查看站点概览和近期内容。

快速开始

面向新手的准备指南，包括常用应用、交易所、Web3 钱包、网络工具、基础术语和安全注意事项。

Web3 入门

了解 Web3 的基础概念、常用工具、账户环境以及参与链上生态需要掌握的基本知识。

交易知识手册

系统学习市场机制、风险管理、价格行为、技术分析、策略验证、交易记录和复盘方法。

VIP 文档

汇总进阶教程、实践资料和会员专属内容。

加密导航

集中整理交易所、行情数据、链上工具、研究平台、钱包和常用加密行业网站。

友链

发现其他值得阅读的个人网站、技术博客和内容社区。

书单

查看交易、投资、金融、技术与个人成长相关的推荐书籍。

即刻

记录简短观点、学习片段、市场观察和日常思考。

写来留待日后慢慢欣赏 😜

苏轼

十年生死两茫茫，
不思量，自难忘。

陆游

红酥手，黄藤酒，
满城春色宫墙柳。

李清照

此情无计可消除，
才下眉头，却上心头。

辛弃疾

众里寻他千百度。
蓦然回首，那人却在，灯火阑珊处。

柳永

多情自古伤离别，
更那堪冷落清秋节！

范仲淹

羌管悠悠霜满地，
人不寐，将军白发征夫泪。

晏殊

无可奈何花落去，
似曾相识燕归来。

岳飞

三十功名尘与土，八千里路云和月。
莫等闲、白了少年头，空悲切！

秦观

两情若是久长时，
又岂在朝朝暮暮。

李之仪

只愿君心似我心，
定不负相思意。

欧阳修

人生自是有情痴，
此恨不关风与月。

唐婉

世情薄，人情恶，
雨送黄昏花易落。

姜夔

二十四桥仍在，
波心荡、冷月无声。

晏几道

琵琶弦上说相思。
当时明月在，曾照彩云归。

李冠

一寸相思千万绪。
人间没个安排处。

宋祁

绿杨烟外晓寒轻，
红杏枝头春意闹。

周彦邦

执手霜风吹鬓影，
去意徊徨，别语愁难听。

万俟咏

短长亭，古今情。
楼外凉蟾一晕生，雨余秋更清。

蒋捷

流光容易把人抛，
红了樱桃，绿了芭蕉。

吴潜

老去惜花心，相对花无语。

刘著

江南几度梅花发，
人在天涯鬓已斑。

贺铸

试问闲情都几许。
一川烟草，满城风絮。梅子黄时雨。

严蕊

不是爱风尘，似被前缘误。
花落花开自有时，总赖东君主。

黄庭坚

若有人知春去处。
唤取归来同住。

张先

天不老，情难绝。
心似双丝网，中有千千结。

晁补之

人生无奈别离何。
夜长嫌梦短，泪少怕愁多。

乐婉

若是前生未有缘，
待重结、来生愿。

朱淑真

把酒送春春不语。黄昏却下潇潇雨。

看完了，跪安吧。╮(╯_╰)╭

Apple ID注册

基本都可以自己注册成功，如果总是注册失败或者不想花时间注册可以看下方的购买方法

一、打开电脑浏览器，收入苹果官网地址：https://appleid.apple.com，点击右上角创建你的Apple ID，进入注册页面

填写姓名，国家或地区选择香港（注册地区），出生日期、邮箱、密码等信息，填写待验证的手机号码，如无香港手机号码，可以选择并填写中国大陆手机号码。

输入图片验证码

查看邮箱收到的验证码，输入到弹出的对话框

查看手机收到的验证码，填入到弹出的对话框

注册成功：

打开iPhone的App Store，输入刚刚注册的邮箱和密码，点击下方的登陆，不是右上角完成。

输入手机收到的验证码。

点击继续

登陆成功

Apple ID购买

因为是购买的ID，购买后注意要修改密码，换绑成自己的邮箱和手机号

如需购买Apple ID，请联系小助理

关于绑定手机号说明
如需要绑定手机号（推荐绑定），点击继续按钮，按页面提示输入手机号绑定即可，注意输入手机号页面选择中国+86（Tip：绑定任意国家手机号都不会改变苹果账号所属国家/地区），当然如果你有其他国家手机号，选择相应区号即可

1. 苹果App用哪个账号下载，就必须哪个账号才能更新

苹果更改资料教程（避免被盗扯皮）

重要提示
修改全部资料包括修改邮箱（AppleID）/密码/密保资料（或绑定手机号），建议先改邮箱，成功修改邮箱后再更改其他资料；如不按教程修改全部资料，此后遇到任何问题或损失自行承担！

登陆苹果官网
打开苹果官方账号管理页面（这是苹果官网，打不开的自行检查你的网络）
https://appleid.apple.com
登陆购买的账号（强调一遍，是登陆你购买的账号改资料）

2. 关于密保问题

各个账号密保问题答案不相同，以购买收到的商品内容为准，答案不需要输入中文。

关于Apple ID安全提示
登陆出现Apple ID安全提示，也就是提示绑定手机升级双重验证，如不想绑定手机就点【其他选项】，再点【不升级】跳过，如下图所示；当然，如果你要绑定手机（推荐，可以用中国手机号码），就点【继续】按钮

3. 更改邮箱（Apple ID）必须！

点击【Apple ID】即可更改邮箱，更改为你自己的邮箱，之后登录就是用此邮箱登录；注意以下几点

更改Apple ID为你自己的邮箱，是你自己的邮箱，不是让你乱编一个邮箱
新邮箱不能是其他苹果账号已经占用的，否则会提示“无法使用此电子邮件地址”
新邮箱不分什么国内国外，任意国家且只要满足以上条件均可
邮箱更改成功后，此苹果账号就是用新邮箱登录，跟原来的旧邮箱没有任何关系了

4. 更改密码/密保资料（必须）

点击【密码】即可更改登录密码
点击【账户安全】即可更改密保资料或绑定手机号码
注意：如果绑定手机号，那密保资料就自动删除了
温馨提示：更改资料过程中会让你再次输入密码确认操作，此时输入的是苹果账号密码，苹果官网不会要求你输入邮箱密码，如果你改了密码，那输入的就是你更改后的苹果密码

5. 关于账单地址（非必须）

此项非必须甚至不建议小白操作
美国购买商品有消费税，所以如果你要自行购买付费商品，请百度找一个美国免税州地址更改账单地址，可以省一点点钱；当然，不更改并不影响账号使用，且不建议小白自行更改，不自行购买付费app的话也不建议修改，防止出现各种奇奇怪怪的问题；同时新设备异地使用余额消费可能导致风控限购，所以本站不建议自行购买付费商品！

6. 关于更改密码出现错误提示

如果更改密码时出现红色“Unexpected HTTP response: undefined undefined”错误提示，可以按以下步骤解决

当前密码、新密码、确认新密码，三个框都输入后
删除新密码输入框内的内容
注意注意：是删除中间输入框里的内容，不要动确认新密码里的内容
从新在中间新密码输入框输入你需要设置的新密码
输入完毕后不要点击任何地方，此时下方的【更改密码】按钮将变成可以点击状态，点击【更改密码】即可

Google Play安装

组件

几大交易所官网链接

https://www.binance.info/zh-CN/activity/referral-entry/CPA?ref=CPA_00EITA059B

注册要点

●注册时建议使用梯子定位到不受限制的地方（中国、美国、俄罗斯等受监管的可能都不行，要么被限制，我习惯定位到台湾、韩国、新加坡等加密友好的地方。

●均可以继续使用身份证进行KYC，护照和其他国家的居住证也可以认证。

币安注册教程

注册建议使用邮箱，推荐注册“google邮箱”（需梯子）

1. 点击访问币安注册链接，填写自己常用的邮箱或手机号（邀请码：LINKJM）

2. 填入验证码，点击下一步

3. 创建自己的秘密，点击下一步

4. 核对验证码，点击下一步

5. 进行实名认证

6. 填入自己身份证一样的真实信息

7. 选择身份证或护照，推荐身份证

8. 点击继续

9. 选择自己方便的验证方式，推荐手机安装币安App

10. 后续上传自己的身份证正反面，扫脸实名认证后等待审核即可。

注册后建议绑定谷歌安全令牌（Google Authenticator），关于Authenticator使用查看下方文章：

Google Authenticator安装使用教程

欧意OKX注册教程

OKX交易所也已经出海，同样推荐使用Gmail邮箱注册。

1.点击OKX优惠注册链接（ 邀请码：70998013）

2. 填入验证码，点击下一步

3. 输入手机号码，点击立即验证

4. 输入收到的手机验证码

5. 选择国家，点击下一步

6. 创建密码，点击下一步，注册成功

7. KYC认证，点击右上角头像图标，选择身份认证

8. 点击个人认证，去认证

9. 点击立即认证

10. 证件类型，推荐选择身份证

11. 下载欧意手机App，完成认证即可

其他交易所

注册过程和币安、欧意OKX类似，用我上面的邀请链接注册即可，没有邀请链接是没有手续费减免的！

VIP 内容包括哪些？

加入 VIP 后，可以阅读和使用以下内容：

• 完整进阶文章：Web3 赚钱路径、链上实操、交易方法与常见问题解析。
• 交易实践教程：中心化交易所、现货与合约交易、仓位管理、止损和复盘等实用内容。
• 空投与链上机会：项目筛选、参与流程、成本控制、安全检查和风险识别方法。
• 账号与工具教程：网络环境、常用账号、Telegram、钱包及辅助工具的配置与使用。
• 配套学习资料：文章、视频、思维导图、PDF 文档、操作清单与工具汇总。
• 持续更新内容：根据行业变化补充新的平台教程、案例和风险提示。

如何加入 VIP？

目前提供两种加入方式，选择其中一种即可。

方式一：通过赞赏加入

你可以通过本站赞赏页面支持 LinkJM，并申请加入 VIP。

前往赞赏页面 →

完成赞赏后，请联系 LinkJM，并提供能够核对的赞赏记录。具体赞赏标准、VIP 有效期及开通方式，以联系确认时的说明为准。

方式二：绑定双平台邀请码

通过 LinkJM 的邀请链接注册并绑定以下两个交易平台，也可以申请加入 VIP：

| 平台 | 邀请码 | 注册入口 |
|

加入 LinkJM VIP

查看 VIP 包含的内容、赞赏加入方式，以及 Binance 和 Bitget 双平台邀请码绑定规则。

需要先说明两点。第一，Apple、OpenAI、SEAGM 的价格、库存、支付方式和订阅入口都可能调整，实际操作以你当前看到的页面为准。第二，账号信息、地区设置、付款行为都应符合平台规则，不建议使用虚假身份信息或来源不明的礼品卡；如果你的主力 Apple ID 已经绑定了家庭共享、云盘、长期订阅和大量购买记录，建议不要随意切区。

一、准备土耳其 Apple ID

最稳妥的做法是单独准备一个土耳其区 Apple ID，只用来安装 App、兑换礼品卡和管理订阅。这样即使后面需要切换地区、注销登录或处理余额，也不会影响主账号的 iCloud、相册、通讯录和已有订阅。

注册时可以准备一个单独邮箱，不一定使用主邮箱，但要确保可以正常接收 Apple 的验证码和安全邮件。手机号可以填写中国大陆手机号，国家区号选择 +86 即可，后续登录、验证和找回账号都会用到它。

账单地址可以借助 1K Tools 土耳其地址生成器 获取。打开页面后点击「生成数据」，复制其中的街道地址、城市、省份和邮编，填入 Apple ID 的账单地址页面即可。这个工具生成的是符合土耳其本地格式的虚拟地址，适合用来解决地址格式校验问题；填写时尽量保持城市、省份、邮编在同一条生成结果里，不要把不同结果混在一起。

地区选择土耳其，姓名、生日等信息按注册页要求填写。Apple 对账号安全比较敏感，新号频繁切换设备、频繁改资料、短时间内大量兑换，都可能触发风控，所以注册完成后不要立刻做太多异常操作。

注册完成后，在 iPhone 上进入「设置」顶部头像，先确认 iCloud 不需要切换。通常只需要切换 App Store 账号：打开 App Store，点击右上角头像，拉到底部退出当前媒体与购买项目账号，再登录土耳其 Apple ID。这样不会影响主 iCloud，只会影响 App Store 下载、更新和订阅支付。

如果 ChatGPT App 在当前地区不可用，可以登录土耳其区 App Store 后搜索下载。已经安装过的用户也可以检查更新，确保使用的是官方 ChatGPT App，不要通过第三方安装包或描述文件安装仿冒应用。

二、在 SEAGM 购买 500 礼品卡

SEAGM 是常见的数字点卡平台。进入网站后搜索 Apple Gift Card，注意选择 Turkey / Turkish 区域，不要买成美国、香港、日本或其他地区的礼品卡。Apple 礼品卡通常只支持同区兑换，买错区域基本无法跨区使用。

面额选择 500 TRY。下单前重点核对三件事：商品区域是否为土耳其，面额是否为 500，商品是否有库存并支持你能使用的支付方式。不同时间平台手续费、汇率和到账速度会变化，实际成本以付款页显示为准。支付完成后，订单页一般会展示兑换码，有时需要等待几分钟人工或系统发码。

拿到兑换码后，不要在公开聊天、截图或网盘里保存。建议复制后立刻到 iPhone 的 App Store 兑换：打开 App Store，点击右上角头像，选择「Redeem Gift Card or Code」或「兑换礼品卡或代码」，粘贴兑换码并确认。成功后，账号余额会增加对应土耳其里拉金额。

如果提示无法兑换，先检查当前 App Store 登录的是否为土耳其 Apple ID，再检查兑换码是否有空格、换行或字符识别错误。区域错误、兑换码已使用、账号风控、余额上限等问题都可能导致失败。遇到这类情况不要反复乱试，先回到 SEAGM 订单页确认商品区域和兑换码状态。

三、在 iPhone 上订阅 ChatGPT / Codex

余额到账后，打开 ChatGPT App，登录你的 OpenAI 账号。进入账号或设置页面，找到升级入口，选择 ChatGPT Plus、Pro 或页面中展示的其他可用套餐。Codex 的使用权益会随 OpenAI 当时的产品和套餐设计变化，因此不要只看教程里的文字判断，最终以 App 内套餐说明和 OpenAI 账号页面展示为准。

点击订阅后，iOS 会弹出 Apple 的系统购买确认框。这里要认真看价格、周期和付款账号。如果付款方式显示为 Apple Account Balance，说明会优先使用刚刚兑换的余额。确认无误后用 Face ID、Touch ID 或密码完成购买。订阅成功后，回到 ChatGPT App 刷新账号状态，通常几秒到几分钟内就会生效。

如果 App 内没有看到升级入口，可以尝试更新 ChatGPT App、重新登录 OpenAI 账号、切换网络，或在 App Store 的订阅管理里检查当前 Apple ID 是否正常。不要频繁创建新号反复试错，这样更容易触发 Apple 或 OpenAI 的安全检查。

四、订阅后的管理与续费

订阅完成后，建议立刻确认续费时间。路径是 App Store 右上角头像，进入「Subscriptions」或「订阅」，找到 ChatGPT。这里可以查看套餐、续费日期、取消订阅入口。即使取消自动续费，通常也可以使用到当前订阅周期结束；如果想持续订阅，则需要保证下次扣款前账号余额足够。

500 TRY 是否够用，取决于当时的 App Store 定价和税费。不要按历史价格做精确预算，购买前先在 ChatGPT App 的付款弹窗里看清楚金额。如果余额不足，可以继续购买同区礼品卡补足。为了降低风控概率，不建议短时间内连续兑换大量礼品卡。

另外，Apple ID 余额一般不能提现，也不一定能转移给其他地区账号。决定充值前最好先确认自己确实需要这个订阅，并且接受余额留在土耳其区账号里的情况。

五、常见问题

1. 可以直接用主 Apple ID 切到土耳其区吗？
不太建议。主账号通常绑定了订阅、家庭共享、付款方式、购买记录和 iCloud 生态，切区可能遇到余额未清零、订阅未取消、媒体资料变化等问题。单独账号更容易管理风险。

2. 为什么已经充值成功，ChatGPT 还是订阅失败？
可能是 App Store 账号和 iCloud 账号混淆、余额不足、账号风控、网络异常，或 OpenAI 当前不支持你看到的购买入口。先确认 App Store 登录的是土耳其 Apple ID，再检查订阅弹窗里的付款账号和金额。

3. Codex 一定包含在这个订阅里吗？
不一定。OpenAI 的产品权益会调整，Codex 相关能力可能跟 Plus、Pro、Team、API 或其他方案绑定。订阅前务必看清 App 内说明和 OpenAI 账号页面，不要只按旧教程判断。

4. 礼品卡在哪里买更安全？
优先选择有订单记录、发码记录、售后渠道的平台。不要购买明显低于市场价、来源不明或个人转卖的兑换码。礼品卡一旦被兑换，售后争议通常比较麻烦。

整个流程的核心其实很简单：账号区域要一致，礼品卡区域要一致，订阅时付款账号要一致。只要这三点不出错，大多数问题都能避免。真正需要谨慎的是账号安全和余额管理：不要把主账号拿来频繁切区，不要一次性充值太多，也不要忽略订阅自动续费时间。

一直以来，从 0 开始构建应用，都是一项复杂的工作。尤其是跨越手机、Web 和桌面平台的程序。

这是一片无尽的复杂海洋，需要把技术堆栈融合在一起，来引导、编译、测试、部署、监控应用程序。

多年来，谷歌一直致力于让多平台程序开发流程更快、更顺畅。

经过几个月的成果，团队成功做出了 Project IDX。

谷歌在创建 Project IDX 时并没有构建新的 IDE（集成开发环境），而是使用 VS Code 作为其项目的基础。这让团队能够专注于与 Codey 的集成，Codey 是谷歌基于 PaLM 2 的编程任务基础模型。Project IDX 支持智能代码补全，可以帮助开发者解答一般编码问题，提供与你正在处理的代码有关的特定问题（包括解释能力）的类似 ChatGPT/Bard 的聊天机器人，以及添加如 “添加注释” 等上下文代码操作的能力。
目前，Project IDX 支持 Angular、Flutter、Next.js、React、Svelte 和 Vue 等框架以及 JavaScript 和 Dart 等语言，后续还将支持 Python、Go 和其他语言。

Project IDX 特性

• 随时随地快速开始：你能够在任何地方、任何设备上进行开发，具有本地开发的全部保真度。每个 Project IDX 工作空间都具有基于 Linux 的虚拟机的全部功能，配合云中托管的通用访问权限。

• 一键导入或从模板创建：从 GitHub 导入现有项目，让你继续之前的进度。还可以创建新项目，预先包含流行框架的模板，包括 Angular、Flutter、Next.js、React、Svelte、Vue 和如 JavaScript、Dart 以及（即将推出的）Python、Go 等语言。IDX 还在积极努力为更多项目类型和框架添加一流支持。

• 跨平台预览：应用成功发布后，需要优化设计和不同平台上的行为（像用户那样预览自己的应用），而 IDX 内置的网络预览（目前只支持 web 预览），和即将推出的完全配置的 Android 模拟器和嵌入式 iOS 模拟器，所有这些都可以直接在浏览器中使用。

• AI 助手：我们花费大量时间编写代码，而人工智能的最新进展创造了巨大的机会，可以让我们的时间变得更加高效。IDX 正在探索 Google 在 AI 领域的创新 —— 包括 为 Android Studio 中的 Studio Bot 提供支持的 Codey 和 PaLM 2 模型、Google Cloud 中的 Duet [4] 等 —— 可以帮助你不仅更快地编写代码，还可以编写更高质量的代码。

• 一键部署：在最后，将应用推向生产方面的一个常见痛点是部署它。通过集成 Firebase Hosting，通过几次点击就可以部署你的 Web 应用的可共享预览，或通过快速、安全和全球托管平台部署到生产环境。由于 Firebase Hosting 支持由 Cloud Functions 提供动力的动态后端，所以它非常适合像 Next.js 这样的全栈框架。

• IDX 申请链接：https://idx.dev/

IDX 背后的 AI 模型 Codey

根据介绍，IDX 由 Codey 提供支持。

在 Google I/O 2023 大会上，谷歌正式发布 Codey。这是一款新型 AI 驱动工具，能够编写并理解代码内容。这款新工具被外界视为谷歌对于 GitHub Copilot 的回应，属于同 Replit 结盟打造的成果。

Codey 基于谷歌的下一代大语言模型 PaLM 2，并采用谷歌自家产品代码及大量合法许可的源代码作为训练素材。更重要的是，Codey 仍在不断学习和发展，从谷歌服务生态系统的各个项目中持续汲取新的力量。

Codey 支持 20 多种编程语言，包括 Go、谷歌标准 SQL、Java、JavaScript、Python 以及 TypeScript。开发者可以通过 Visual Studio Code、JetBrains IDE、Google Shell 编辑器以及 Google Cloud 托管工作站服务的扩展来访问 Codey。开发者能够直接在 IDE 的聊天框中与该模型交流（例如 Android Studio Bot），或者在文本文件中编写注释以指示其生成相关代码。它支持各种编码任务，通过以下方式帮助开发人员更快地工作并缩小技能差距：

代码完成：Codey 根据提示中输入的代码上下文建议接下来的几行。

代码生成：小程根据开发人员的自然语言提示生成代码。

代码聊天：Codey 允许开发人员与机器人对话，以获得调试、文档、学习新概念和其他与代码相关问题的帮助。

Codey 在处理与编码相关的提示词方面接受了专门训练，谷歌还通过其他训练让该模型学会了处理关于 Google Cloud 的一般查询。

目前在用的辅助AI开发工具

- CodeGeeX 智能编程助手

• 代码自动生成和补全 CodeGeeX可以根据自然语言注释描述的功能自动生成代码，也可以根据已有的代码自动生成后续代码，补全当前行或生成后续若干行，帮助你提高编程效率。
• 提供代码翻译能力 基于AI大模型对代码进行语义级翻译，支持多种编程语言互译
• 自动添加注释 CodeGeeX可以给代码自动添加行级注释，节省大量开发时间。没有注释的历史代码，也不再是问题。

基于CodeGeeX2: 更强大的多语言代码生成模型
是多语言代码生成模型 CodeGeeX (KDD’23) 的第二代模型。不同于一代 CodeGeeX（完全在国产华为昇腾芯片平台训练） ，CodeGeeX2 是基于 ChatGLM2 架构加入代码预训练实现，得益于 ChatGLM2 的更优性能，CodeGeeX2 在多项指标上取得性能提升（+107% > CodeGeeX；仅 60 亿参数即超过 150 亿参数的 StarCoder-15B 近 10%），更多特性包括：

• 更强大的代码能力：基于 ChatGLM2-6B 基座语言模型，CodeGeeX2-6B 进一步经过了 600B 代码数据预训练，相比一代模型，在代码能力上全面提升，HumanEval-X 评测集的六种编程语言均大幅提升 (Python +57%, C++ +71%, Java +54%, JavaScript +83%, Go +56%, Rust +321%)，在 Python 上达到 35.9% 的 Pass@1 一次通过率，超越规模更大的 StarCoder-15B。
• 更优秀的模型特性：继承 ChatGLM2-6B 模型特性，CodeGeeX2-6B 更好支持中英文输入，支持最大 8192 序列长度，推理速度较一代 CodeGeeX-13B 大幅提升，量化后仅需 6GB 显存即可运行，支持轻量级本地化部署。
  更全面的 AI 编程助手：CodeGeeX 插件（VS Code, Jetbrains）后端升级，支持超过 100 种编程语言，新增上下文补全、跨文件补全等实用功能。结合 Ask CodeGeeX 交互式 AI 编程助手，支持中英文对话解决各种编程问题，包括且不限于代码解释、代码翻译、代码纠错、文档生成等，帮助程序员更高效开发。
• 更开放的协议：CodeGeeX2-6B 权重对学术研究完全开放，填写登记表申请商业使用。

- AWS CodeWhisperer

4月18日，亚马逊云科技宣布，实时AI编程助手Amazon CodeWhisperer正式可用，同时推出的还有供所有开发人员免费使用的个人版（CodeWhisperer Individual）。CodeWhisperer帮助开发者基于注释生成代码，追踪开源参考，扫描查找漏洞。此外，还可以帮助开发者创建代码胜任如下场景，比如常规、耗时的无差别任务，或是在使用不熟悉的API或SDK时构建示例代码，亦或要正确高效地使用亚马逊云科技API操作，还有其他场景比如编写读写文件、处理图像、编写单元测试等代码。

Amazon CodeWhisperer 为多种编程语言提供基于人工智能（AI）的代码建议，包括 Python、Java、JavaScript、TypeScript、C#、Go、Rust、PHP、Ruby、Kotlin、C、C++、Shell 脚本、SQL 和 Scala。您可以使用来自多个 IDE 的服务，包括 JetBrains IDE（IntelliJ IDEA、PyCharm、WebStorm 和 Rider）、Visual Studio（VS）Code、AWS Cloud9、AWS Lambda 控制台、JupyterLab 和 Amazon SageMaker Studio。

- Poe

国内可注册，使用方便，免费，有针对代码和程序专门优化的gpt-3.5-turbo模型 Assistant
当然还有其他的模型，包含一些限额和付费的，你也可以创建自己的bot

• Claude-2-100k
• Claude-instant-100k
• gpt-4-32k（Powered by gpt-4-32k. Since this is a beta model, the usage limit is subject to change.）
• Google-PaLM（Powered by Google's PaLM 2 chat-bison-001 model）

CodeGeeX2和AWS CodeWhisperer都提供了VSCode的插件可以使用，体验下来，CodeGeeX2支持的文件类型更多一点，而且反应也还算迅速，AWS CodeWhisperer只支持了主流开发语言，对于如dart、Vue、markdown、CSS等非主流编程语言支持效果很差，目前两者都免费，体验下来CodeGeeX2更不错一点，根据注释生成代码，给现有代码生成注释，代码翻译，纠错等功能也比较实用

Some thoughts🤔

看来云上开发将来一定是主流趋势，程序员再也不用因为换设备，换环境而苦恼，集成式一体开发环境，开箱即用，开发随时可中断，可恢复，不受限于设备，环境，地点影响
而且集成AI代码助手，各大厂家都在发力了，微软的GitHub Copilot,亚马逊的CodeWhisperer，还有即将到来的Google的Project IDX 方便快捷的开发，将大量繁琐重复的工作交给AI来执行

That's It

参考资料：

• OSC 开源社区（ID：oschina2013)
• https://developers.googleblog.com/2023/08/introducing-project-idx-experiment-to-improve-full-stack-multiplatform-app-development.html
• https://codeandhack.com/google-codey/

面向：正在使用 Cursor、Claude Code、Codex、GitHub Copilot、Gemini CLI、Windsurf 等 AI 编程工具的研发团队。

目标：理解 OpenSpec 解决什么问题、如何在 IDE 和 CLI 中落地、典型工作流、注意事项和示例。

这份术语表用于建立初步认识。后续章节会进一步解释其中的重要概念。

网络与基础设施

区块链（Blockchain）

一种由多个参与者共同维护的数据记录系统。交易会被整理进区块，并按照规则连接起来。区块链并非绝对“不可修改”，而是通过密码学、共识机制和经济成本，让已经确认的记录难以被单方面更改。

节点（Node）

运行区块链软件并参与网络通信的计算机。不同节点可能负责保存数据、验证交易、传播信息或生成区块。

共识机制（Consensus Mechanism）

网络参与者对交易顺序和账本状态达成一致的方法。常见类型包括工作量证明和权益证明，不同机制在安全、性能与资源消耗之间有不同取舍。

公链（Public Blockchain）

任何人通常都可以读取数据、发送交易或参与验证的开放区块链网络。比特币和以太坊是典型公链。

Layer 1（L1）

区块链的基础网络，负责共识、结算和数据记录，例如比特币、以太坊和 Solana。

Layer 2（L2）

建立在基础链之上的扩容系统。它在链外或独立环境中处理部分交易，再把结果提交给基础链，以降低成本或提高处理能力。

智能合约（Smart Contract）

部署在区块链上的程序。满足预先设定的条件时，网络会按照代码执行操作。智能合约可以公开验证，但代码公开并不代表它没有漏洞。

Gas

执行链上操作所消耗计算和存储资源的计量方式。用户支付的网络费用通常由 Gas 用量和当时的费率共同决定。

预言机（Oracle）

向智能合约提供链外数据的机制，例如价格、天气或比赛结果。预言机提供的数据是否可靠，会直接影响依赖它的应用。

跨链桥（Bridge）

用于在不同区块链之间传递资产或信息的协议。跨链桥需要解决多条网络之间的验证问题，也是历史上安全事件较集中的基础设施之一。

账户、钱包与身份

地址（Address）

区块链账户的公开标识，可用于接收资产或查询公开记录。公开地址通常可以分享，但它不等于私钥。

私钥（Private Key）

控制链上账户并签署交易的秘密数据。拥有私钥通常意味着拥有对应账户的控制权；私钥一旦泄露，资产可能无法追回。

助记词（Seed Phrase）

用于恢复钱包密钥的一组单词。它本质上是账户控制权的备份，不应截图、上传网盘或发送给任何人。

钱包（Wallet）

管理密钥、生成地址并与区块链交互的工具。钱包通常不直接“存放”资产；资产记录在链上，钱包保存的是访问和操作这些资产所需的凭证。

签名（Signature）

用户使用私钥对操作进行授权的密码学证明。签名交易会改变链上状态；某些链下签名也可能授予重要权限，不能因为“不花 Gas”就放松警惕。

DID（Decentralized Identifier）

去中心化标识符。它尝试让个人或组织在不依赖单一身份提供商的情况下创建和控制数字身份标识，但具体实现和采用程度因项目而异。

资产与代币

比特币（Bitcoin / BTC）

比特币既指一套点对点价值转移网络，也指该网络中的原生资产 BTC。其发行上限和发行节奏由协议规则设定。

以太坊（Ethereum）与 ETH

以太坊是支持智能合约的区块链网络，ETH 是其原生资产，用于支付网络费用、参与网络安全以及在生态应用中作为资产使用。

代币（Token）

由区块链或智能合约记录的数字单位，可以表达支付资产、使用权、治理权或其他权益。代币名称相似，不代表权利、价值或风险相同。

同质化代币（Fungible Token）

同一合约中的每个单位可以相互替代，例如一个单位通常与另一个单位具有相同属性。以太坊上的 ERC-20 是常见标准之一。

NFT（Non-Fungible Token）

非同质化代币。每个代币可以拥有不同的编号或元数据，常用于表示收藏品、凭证、会员资格或游戏资产。NFT 证明的是链上记录关系，不自动等同于作品版权。

稳定币（Stablecoin）

目标是相对某种参考资产保持价格稳定的代币，常见参考对象是法定货币。不同稳定币可能依赖现金储备、加密资产抵押或算法机制，因此风险结构并不相同。

BRC-20

一种利用比特币 Ordinals 相关机制记录同质化代币信息的实验性标准。它与以太坊 ERC-20 的实现方式不同，也不具备完全相同的智能合约能力。

应用与组织

dApp（Decentralized Application）

与区块链或智能合约交互的应用。前端网站仍可能由中心化服务器提供，因此“使用区块链”不代表整个产品完全去中心化。

DeFi（Decentralized Finance）

建立在公开区块链和智能合约上的金融应用集合，包括交易、借贷、衍生品和资产管理等。DeFi 减少了部分人工中介，但增加了合约、预言机、流动性和治理风险。

DEX（Decentralized Exchange）

通过智能合约完成资产交换的去中心化交易协议。用户通常直接使用钱包交互，但仍需承担滑点、恶意代币和合约安全风险。

DAO（Decentralized Autonomous Organization）

通过公开规则、智能合约和社区协作进行治理的组织形式。DAO 的去中心化程度差异很大，需要观察投票权、资金控制权和实际决策过程。

GameFi

将游戏机制与可交易数字资产、代币激励或链上所有权结合的应用类型。游戏体验和资产经济模型需要分别评估。

交易与市场

中心化交易所（CEX）

由公司运营并代用户保管资产、撮合交易的平台。使用方便，但用户需要承担平台运营、托管、合规和账户限制等风险。

流动性（Liquidity）

在不显著影响价格的情况下完成买卖的能力。流动性不足时，即使页面显示某个价格，也可能无法按该价格成交。

滑点（Slippage）

预期成交价格与实际成交价格之间的差异。交易规模、市场波动、流动性和交易确认速度都会影响滑点。

TVL（Total Value Locked）

锁定总价值，用于描述某个协议或网络中存入资产的估算价值。TVL 可以辅助观察规模，但不能单独证明协议安全或项目具有投资价值。

ICO（Initial Coin Offering）

首次代币发行，一种通过出售代币筹集资金的方式。代币发行不等同于股票上市，购买者获得的权利也可能非常有限。相关活动受到不同司法辖区的监管约束，并伴随较高风险。

常见中文俗称

| 俗称 | 通常指代 |
|

理解 Web3，不应从“某个代币会不会上涨”开始，而应先看互联网中的权利如何分配：谁保存数据、谁制定规则、谁控制账户，以及用户能否带走自己的资产和关系。

从 Web1、Web2 到 Web3

人们常用 Web1、Web2 和 Web3 描述互联网不同阶段的主要特征。这种划分是一种理解框架，并不是严格的技术版本号。

| 阶段 | 用户的主要行为 | 内容和账户的控制方式 | 典型特征 |
|

学习这些内容的目的不是背诵技术名词，而是建立一套分析框架。当你遇到一条新链或新协议时，能够判断它负责哪一层、依赖谁提供安全性，以及为了提升性能作出了哪些取舍。

Web3 系统的基本分层

Web3 应用通常不是由单一程序完成，而是由多个层次共同组成：

| 层次 | 主要职责 | 常见风险 |
|

不过，“钱包”这个名字很容易造成误解：链上资产并不存放在钱包软件里，而是记录在区块链上。 钱包真正保管的是能够控制账户的密钥，并帮助用户创建地址、查询资产和完成签名。

理解这一点，是建立 Web3 安全意识的第一步。

1. 地址、密钥与资产是什么关系

一个典型的区块链账户，可以先用下面这组关系来理解：

• 私钥：账户控制权的根源，用来生成数字签名。
• 公钥：由私钥推导而来，可以公开，用于验证签名。
• 地址：通常由公钥进一步计算得到，是对外收款和识别账户的标识。
• 链上资产：记录在区块链状态中，由网络根据规则确认归属。

地址可以类比为公开的收款编号，但私钥不能简单等同于银行卡密码。银行卡密码泄露后，银行可能协助冻结账户或重置凭证；私钥一旦泄露，攻击者通常可以直接签署交易，而区块链上并不存在一个必然能够撤销交易的中心机构。

因此需要记住一条最重要的规则：

地址可以公开，私钥和助记词永远不能公开。

2. 钱包到底做了什么

钱包通常承担以下几项工作：

1. 创建或导入账户：生成密钥，或者通过助记词恢复已有账户。
2. 管理多个地址：同一组助记词可以按照确定的规则派生出多个地址。
3. 读取链上数据：展示余额、代币、NFT 和交易记录。
4. 构造交易：把收款地址、金额、网络费用等信息整理成网络可识别的数据。
5. 请求并完成签名：用户确认后，用私钥对交易或消息进行签名。
6. 广播交易：把签名后的交易发送给区块链网络。

钱包界面里显示的资产，本质上是它读取链上数据后形成的视图。即使卸载钱包应用，只要私钥或助记词仍然安全，通常仍可在兼容钱包中恢复账户；反过来，如果密钥丢失，仅保留钱包应用也无法重新取得控制权。

3. 私钥、助记词和钱包密码

这三个概念经常被混在一起，但它们的权限完全不同。

私钥

私钥是一段具有极大随机性的数字。谁能使用私钥签名，谁就能控制对应账户。不要截图、不要通过聊天工具传输，也不要粘贴到来历不明的网站。

助记词

助记词通常由 12 个或 24 个单词组成，它可以按照既定标准派生出一组私钥和地址。它不是普通的“找回密码”，而更接近整个钱包的主钥匙。

一组助记词可能控制多个网络、多个地址和多类资产。泄露助记词的后果，往往比泄露单个账户的私钥更严重。

钱包密码

钱包密码一般用于解锁当前设备中的钱包应用，或加密本地密钥文件。它不一定能够在另一台设备上恢复链上账户，也不能替代助记词备份。

| 凭证 | 主要用途 | 丢失后的影响 | 是否可以告诉他人 |
|

DeFi 是 Decentralized Finance 的缩写，中文通常译为“去中心化金融”。它并不意味着所有环节都完全去中心化，也不代表产品天然安全。更准确的理解是：资产由区块链记录，业务规则由智能合约执行，用户可以在满足协议条件时直接参与。

本篇只讨论运行机制和风险，不构成任何投资建议。

1. DeFi 是一组可以组合的金融积木

DeFi 不是某个单独的应用，而是由钱包、稳定币、交易协议、借贷协议、预言机和区块链等组件共同构成的生态。

一次看似简单的链上兑换，背后可能经过以下环节：

1. 用户连接钱包并发起交易。
2. 钱包展示合约调用内容并请求签名。
3. 交易协议根据流动性和价格规则计算结果。
4. 智能合约转移两种资产并更新状态。
5. 区块链验证、排序并最终确认交易。

不同协议之间通常可以互相调用，这种特性被称为可组合性。它能加快产品创新，也会传导风险：底层稳定币、预言机或协议出现问题，上层应用可能同时受到影响。

2. 稳定币为什么是 DeFi 的基础工具

比特币、以太币等加密资产的市场价格会持续变化。如果每一次支付、借贷和结算都使用高波动资产，用户很难判断自己实际承担了多少债务或购买力变化。

稳定币试图锚定某种参考资产，最常见的是美元。它为链上世界提供了较稳定的计价和结算单位，常见用途包括：

• 在不同加密资产之间提供交易媒介。
• 作为借贷协议中的存款、借款或抵押资产。
• 用于跨境转账和链上支付。
• 在市场波动期间暂时承担结算工具的角色。

需要特别注意：“稳定”是设计目标，不是兑付保证。 稳定币仍可能偏离目标价格，也就是常说的“脱锚”。

3. 三类常见的稳定机制

稳定币的关键问题不是名称，而是：谁发行、用什么支撑、如何赎回，以及系统失效时损失由谁承担。

法币储备型

发行方接收法币或其他低波动资产，并发行对应数量的链上代币。用户理论上可以按照规则把稳定币交还给发行方，换回其锚定的法币。

这类稳定币的核心依赖包括：

• 储备资产是否真实、充足并且流动性良好。
• 托管银行和发行机构是否稳健。
• 审计或鉴证信息是否及时、可信。
• 用户是否具备直接赎回资格。
• 发行方是否有权冻结特定地址。

它在价格稳定性上往往较直观，但信任并没有消失，而是集中到了发行、托管和监管环节。

USDT 与 USDC

USDT 和 USDC 都属于中心化发行的美元稳定币。两者都试图让一枚代币维持接近一美元的价值，但它们不是银行账户中的美元，也不是由区块链自动保证价格永远等于一美元。

| 项目 | USDT | USDC |
|

NFT 的核心能力，是在区块链上创建一个可以识别、持有和转移的独特记录。它可以关联图片、游戏道具、门票或会员权益，也可以只是一个不具备额外用途的链上收藏品。

理解 NFT，首先要把“链上的代币”“代币指向的内容”和“持有人获得的权利”分开。

1. NFT 到底是什么

NFT 是 Non-Fungible Token 的缩写，通常译为“非同质化代币”。

“非同质化”表示每个代币可以具有独立编号和属性，不能默认与另一个代币一比一互换。例如，一张特定座位的门票和另一张门票虽然属于同一场活动，但座位、权益和价格可能不同。

与之相对，同一种普通代币的各个单位通常可以相互替代。你持有的一枚代币，与他人持有的同种一枚代币，在协议层面没有编号和属性差异。

NFT 通常包含以下链上信息：

• 所属智能合约的地址。
• 在合约中的 Token ID。
• 当前持有地址。
• 指向元数据的链接或编码内容。
• 转移、授权和销毁等操作记录。

因此，一个 NFT 的准确身份通常不是它的名称或图片，而是：

区块链网络 + 合约地址 + Token ID

不同合约完全可以创建名称和图片相同的 NFT。只看图片，无法判断它是不是某个项目的官方资产。

2. NFT、元数据和图片是三层结构

人们常说“把一张图片铸造成 NFT”，但多数情况下，图片本身并没有完整写入区块链。更常见的结构分为三层：

第一层：链上代币

智能合约记录 Token ID、持有地址、授权关系等信息。这是 NFT 能够在钱包间转移并被应用识别的基础。

第二层：元数据

元数据描述 NFT 的名称、简介、属性和媒体文件位置，常见格式是 JSON。合约可能直接保存元数据，也可能只保存一个指向元数据的 URI。

第三层：媒体文件

图片、视频、音频或三维模型通常体积较大，可能存放在去中心化存储网络、项目服务器或其他内容分发系统中。

三层结构带来一个重要结论：链上代币仍然存在，不代表它指向的内容永远可访问。 如果元数据依赖的服务器停止运行，或者合约允许管理员修改链接，钱包里看到的名称和图片可能发生变化。

核验 NFT 时，不仅要看代币在不在链上，还要查看元数据存在哪里、能否修改、由谁维护。

3. 常见的 NFT 代币标准

不同区块链有不同的 NFT 标准。以 EVM 生态为例，常见标准包括 ERC-721 和 ERC-1155。

ERC-721

ERC-721 为每个 NFT 提供独立的 Token ID，适合一件件区分的收藏品、证书、域名和独特游戏道具。

ERC-1155

ERC-1155 允许一个合约同时管理多类资产，同一个 Token ID 也可以发行多个数量。它适合游戏道具、票券和同时包含同质化与非同质化资产的场景。

| 对比项 | ERC-721 | ERC-1155 |
|

早期 GameFi 常用“边玩边赚”吸引用户，但如果只把它理解成一种赚钱工具，就会忽略最重要的问题：奖励从哪里来，玩家为什么愿意长期留下，以及资产离开游戏后还有没有用途。

一个健康的链上游戏，首先应当是一款有人愿意玩的产品，其次才是资产和经济系统。

1. 什么是区块链游戏

区块链游戏会把一部分游戏数据或规则放到区块链上，例如：

• 用 NFT 表示角色、卡牌、土地或装备。
• 用同质化代币作为游戏资源或治理工具。
• 通过智能合约完成铸造、交易、合成和奖励分配。
• 允许玩家使用钱包登录并自行保管部分资产。
• 把关键规则和游戏状态公开在链上。

但这不代表所有操作都必须上链。角色移动、画面渲染、实时战斗和反作弊等高频行为，通常仍由客户端和服务器处理。

把所有动作写入区块链会带来等待确认、手续费和吞吐量问题。常见做法是让游戏体验留在链下，只把资产转移、关键结果或需要公开验证的规则放到链上。

2. 链上资产真的完全属于玩家吗

如果游戏装备以 NFT 形式存放在玩家钱包中，开发者通常不能像修改中心化数据库那样直接删除钱包里的代币。玩家还可能把它转移到兼容市场或另一个地址。

不过，“代币仍在钱包中”和“资产仍然有用”是两回事。

假设你拥有一把链上宝剑：

1. NFT 合约仍然存在，因此钱包还能证明你持有这枚代币。
2. 宝剑图片可能存放在项目服务器；服务器关闭后，图片可能无法加载。
3. 攻击力和战斗效果由游戏服务器解释；游戏停止运行后，这些能力可能失去意义。
4. 另一款游戏不会自动认识这把宝剑，除非新开发者主动读取并适配它。

因此，链上所有权主要保证的是代币的持有与转移记录，不能保证游戏持续运营、资产价格稳定或跨游戏通用。

3. GameFi 的三类资产

游戏 NFT

角色、装备、卡牌和土地经常被设计成 NFT。它们可以具有等级、稀有度和技能等属性，也可能被用于合成或繁殖。

检查游戏 NFT 时，需要判断哪些属性写在链上、哪些由服务器保存，以及开发者能否修改元数据和游戏效果。

功能代币

功能代币通常用于升级、修理、合成、繁殖、门票或其他日常消耗。玩家可能通过游戏行为获得它，再在游戏内消耗。

如果代币不断产出，却缺少有意义的消耗场景，供给会持续增加，卖出压力也会逐渐积累。

治理代币

治理代币可能用于投票、质押或分享部分生态权益。它与功能代币可以是同一种资产，也可以采用双代币结构。

“可以投票”不等于玩家能够决定所有规则。需要查看团队、投资者和社区的代币分布，以及投票结果是否真正约束开发者。

4. 游戏经济如何形成循环

GameFi 经济系统通常同时存在发行端和消耗端。

发行端可能包括战斗奖励、任务奖励、排行榜、质押和活动空投；消耗端可能包括升级、修理、合成、繁殖、报名和装饰品。

一个简单的铁匠铺案例

假设游戏每天向玩家奖励 100 万枚矿石代币：

• 玩家打造武器每天只消耗 20 万枚。
• 剩余代币没有其他用途，大量玩家选择卖出。
• 代币价格下跌后，“挖矿奖励”的吸引力下降。
• 新玩家减少，武器需求继续下降。
• 为吸引用户而提高奖励，又会加快代币增发。

问题并不是奖励存在，而是产出长期高于真实消耗。

如果开发者增加装备维修、赛季报名和高价值合成，确实可以提高消耗，但这些设计只有在游戏本身好玩、玩家自愿参与时才有效。为了维持代币价格而制造无意义消耗，只会把问题推迟。

5. 案例一：Axie Infinity 的繁殖经济

Axie Infinity 是早期具有代表性的收藏与战斗类链游。玩家使用数字宠物参与战斗，并可以消耗游戏资源繁殖新的宠物。

它的经济结构可以简化为：

1. 新玩家需要获得宠物才能参与部分玩法。
2. 玩家通过游戏获得功能型资源。
3. 繁殖宠物需要消耗相应资源。
4. 新宠物可以进入市场，供其他玩家购买和使用。

为什么早期循环能够运转

当新玩家持续进入时，宠物需求提高，繁殖就有吸引力；繁殖消耗游戏代币，代币也获得了使用需求。玩家、繁殖者和市场形成正向循环。

循环为什么容易失衡

宠物能够不断繁殖，意味着供应会增长。如果新增玩家和宠物消耗速度低于繁殖速度，市场供给就可能超过需求。与此同时，玩家持续获得并卖出奖励，会形成额外卖压。

Axie 的官方经济说明也曾明确讨论人口增长、奖励发行、资源消耗和对新增参与者的依赖。这一案例说明：玩家拥有资产并不能代替供需管理。

参考：Axie Infinity 官方经济说明

从案例中学到什么

• 可繁殖资产必须有供应上限或足够强的消耗机制。
• 新玩家需求不应成为系统唯一的价值来源。
• 经济参数需要持续调整，但频繁改动也会损害玩家预期。
• 奖励应更多来自游戏服务收入，而不是单纯增发代币。

6. 案例二：STEPN 的运动激励和双代币模型

STEPN 把户外运动、NFT 运动鞋和代币奖励结合起来。用户装备符合条件的运动鞋，在特定规则下步行或跑步，消耗能量并获得游戏代币。

它提供了一个清晰的游戏化设计案例：现实行为通过手机传感器和反作弊系统验证，再转换成游戏奖励。

双代币分别解决什么问题

其设计中包含功能代币与治理代币：

• 功能代币用于游戏中的日常获得与消耗。
• 治理代币承担更长期的治理或高级功能。
• NFT 运动鞋决定部分属性、能量和奖励能力。

用户可以把功能代币用于修理、升级、合成等操作。这样的“代币水槽”用于减少流通中的供给。

一个玩家选择案例

假设玩家今天获得 30 枚功能代币，他可以：

• 全部卖出，形成市场供给。
• 用于修理运动鞋，维持后续使用。
• 用于升级属性，换取未来可能的效率提升。
• 与其他资源组合，尝试生成新资产。

如果大多数玩家认为升级没有意义，就会倾向于卖出；如果所有人都只为获得收益而运动，代币买方可能不足。因此，经济平衡不仅取决于消耗按钮有多少，还取决于玩家是否真正需要这些功能。

参考：STEPN 官方白皮书

从案例中学到什么

• 把现实行为游戏化，可以扩大 GameFi 的使用场景。
• 反作弊是经济安全的一部分；虚假运动等同于无成本增发奖励。
• 双代币可以分离日常使用与治理，但不会自动解决供需失衡。
• 当进入成本和回本预期成为主要讨论时，游戏体验往往退居其次。

7. 案例三：Sorare 将现实比赛数据引入卡牌游戏

Sorare 是梦幻体育类游戏。玩家收集数字球员卡，组成阵容，游戏得分与现实比赛中的球员表现相关。

这个案例与纯粹的“做任务获得代币”不同，它把 NFT 的效用与外部数据结合起来：

1. 卡牌代表特定球员和赛季版本。
2. 玩家用卡牌组成参赛阵容。
3. 现实比赛数据通过数据服务进入游戏。
4. 游戏根据表现计算分数和排名。

为什么它具有持续使用场景

球迷本来就有关注球队、球员和比赛的需求。卡牌既可以收藏，也可以参与阵容策略。其使用价值不完全依赖“今天能获得多少代币”，而与体育内容和游戏竞争有关。

它增加了哪些新依赖

这种模式仍然依赖：

• 体育联盟与球员形象的授权。
• 现实比赛和数据供应商。
• 游戏评分规则的公平性。
• 卡牌发行量与赛季更新机制。
• 项目在不同地区适用的监管规则。

参考：Sorare 官方玩法介绍

从案例中学到什么

• 链上资产可以与现实内容结合，形成持续效用。
• 现实数据为玩法提供变化，也引入预言机和授权风险。
• “资产属于玩家”不意味着项目方失去对比赛规则的控制。
• 游戏的长期吸引力可以来自兴趣和竞争，而不仅是代币奖励。

8. 案例四：全链上策略游戏

另一类实验性产品会把地图状态、资源规则、行动结果和胜负条件尽可能写进智能合约。这类产品常被称为全链上游戏。

一个链上星际探索案例

假设每个星球的位置和归属都记录在链上：

1. 玩家提交探索或移动指令。

2. 合约验证距离、资源和冷却时间。

3. 合法操作改变星球归属和资源状态。

4. 任何人都可以读取规则，并开发新的地图界面或数据工具。

如果官方网页停止服务，社区仍有可能为同一套链上状态开发新的客户端。这是全链上设计相较传统服务器游戏最独特的地方。

为什么不是所有游戏都适合全上链

• 每次操作都可能产生手续费和确认等待。
• 公开状态可能让隐藏信息和反作弊更困难。
• 合约升级比服务器更新更复杂。
• 实时动作和高频交互对性能要求极高。
• 错误规则部署后，修复可能需要治理或迁移。

因此，全链上更适合回合制、策略、模拟经营等允许较慢交互的类型，而不一定适合所有实时竞技游戏。

9. 四种设计模式放在一起看

| 案例模式 | 区块链承担的角色 | 主要需求来源 | 核心风险 |
|

DAO 并不是“没有管理者的公司”，也不是把每件事都交给所有成员投票。现实中的 DAO 往往同时包含论坛讨论、核心团队、工作组、多签委员会和链上治理，是一套技术规则与社会协作混合而成的组织方式。

理解 DAO 的关键，是回答四个问题：谁能提出建议、谁有决定权、谁负责执行、谁为错误承担责任。

1. DAO 解决什么问题

假设一群来自不同国家的开发者和用户共同维护一个开源协议。协议积累了一笔收入，需要决定如何升级产品、资助开发和处理安全事故。

传统做法是成立公司，由董事会和管理层决策。DAO 则尝试把部分组织规则公开化：

• 成员通过钱包证明身份或治理权。
• 提案与讨论可以被所有人查看。
• 投票权按照预先约定的规则计算。
• 共同资金由多签钱包或智能合约管理。
• 通过的链上提案可以自动执行。
• 决策和资金流留下可审计记录。

这让跨地域协作更容易，但不会消除人的判断、谈判、利益冲突和法律责任。

2. 一个 DAO 通常由哪些部分组成

共同目标

DAO 需要明确自己为何存在，例如维护借贷协议、管理域名系统、资助公共产品或收藏数字艺术。没有共同目标的代币持有人，并不会自动形成有效组织。

成员与治理权

成员资格可能来自治理代币、NFT、贡献记录、邀请或现实身份。不同资格可以对应不同权利，例如讨论、提案、投票、领取预算或代表工作组。

治理规则

治理规则包括提案门槛、投票方式、法定人数、通过比例、执行延迟和紧急权限。规则可以写入智能合约，也可以由章程和社区共识约束。

金库

DAO 金库用于保存代币、稳定币或其他资产，并为开发、运营、研究和社区项目提供预算。公开地址让任何人能够查看余额和转账，但无法自动证明每一笔支出都合理。

执行者

投票通过后仍然需要执行。执行者可能是智能合约、多签成员、基金会、公司或工作组。判断 DAO 是否真正去中心化，不能只看投票界面，还要看最终控制密钥在谁手中。

3. 一项提案如何变成实际行动

成熟的治理不会从一个想法直接跳到资金转账，通常会经历多个阶段。

讨论

成员在论坛或社区中说明问题，收集反对意见，并判断它是否值得进入正式流程。

正式提案

提案需要写清目标、预算、时间表、负责人、验收标准和链上操作。涉及合约调用时，还要提供可以被审查的执行数据。

意见投票

社区可以先进行不直接执行的“温度检查”，观察支持度。此类投票成本较低，但结果可能只是社会信号。

正式投票

符合门槛的提案进入正式表决。系统会检查投票时间、投票权、法定人数和通过比例。

时间锁

通过的提案可以先进入一段等待期。时间锁让用户有机会发现恶意操作、撤出资产或采取防御措施。

执行

链上治理可以在等待期结束后调用合约或转移资金；链下治理则需要多签委员会或工作组按照结果执行。

一个社区工具资助案例

假设开发者申请 50,000 枚稳定币制作数据看板。一个完整提案至少应包含：

1. 看板解决什么问题，目标用户是谁。
2. 负责人过去完成过哪些项目。
3. 资金分几期支付，每期交付什么成果。
4. 源代码和数据是否向社区开放。
5. 项目延期或停止时，剩余预算如何处理。
6. 谁负责验收，争议如何解决。

投票只能决定“是否授权”，不能代替项目管理。使用分期拨款、里程碑和公开报告，通常比一次性支付全部资金更稳妥。

4. DAO 常见的四种决策机制

一人一票

每名合格成员拥有相同票数，形式上较平等。但系统需要解决一个人创建多个身份的问题，这被称为女巫攻击。

适用场景包括有明确成员审核的小型社区、合作组织或使用可信身份凭证的投票。

代币加权投票

持有的治理代币越多，投票权越大。它容易在开放网络中计算，也让承担较大经济风险的人拥有更高权重。

缺点是财富可能转化为治理控制权。早期团队、投资机构和大户可能主导结果，小额成员即使人数很多也难以影响决策。

委托投票

成员把投票权委托给更愿意研究提案的代表，代币通常仍保留在原钱包中。委托可以提高专业程度和参与率，也会形成具有持续影响力的代表群体。

评估委托制度时，要看委托能否随时更换、代表是否公开披露利益冲突，以及投票记录是否透明。

多签委员会

多签钱包要求多名成员中的一定数量共同签名。例如五名成员中至少三人签名，资金才能转出。

多签适合日常付款和紧急响应，执行速度通常快于全体投票。但签名人数量过少、身份关联或缺乏监督，会形成新的中心化风险。

机制组合比单一机制更常见

一个 DAO 可以让代币持有人决定重大方向，让工作组处理日常运营，再由多签钱包执行预算。不同决策使用不同机制，往往比“所有事情全民投票”更有效。

5. 法定人数、通过比例和投票门槛

治理参数决定少数人能否代表整个社区。

• 提案门槛：发起正式提案需要达到的投票权或支持量，用于减少垃圾提案。
• 法定人数：一项投票至少需要多少参与权重才有效。
• 通过比例：有效投票中需要多少赞成票才能通过。
• 投票周期：成员可以参与表决的时间长度。
• 执行延迟：通过后等待多久才能执行。

一个法定人数案例

某 DAO 一共有 100 万票治理权：

• 只有 2 万票参与投票。
• 其中 1.5 万票赞成，5 千票反对。
• 赞成比例是 75%，看似获得明显支持。

如果该 DAO 规定法定人数为 10 万票，这项提案仍然无效。法定人数防止极少数活跃成员在其他人不知情时控制组织。

但法定人数设置过高，也可能让任何提案都无法通过。治理设计是在安全、代表性和执行效率之间寻找平衡。

6. 多签和时间锁为什么重要

多签降低单点密钥风险

如果金库只由一个私钥控制，密钥泄露或持有人失联都可能造成严重后果。多签把执行权分散到多个签名人。

良好的多签安排还应考虑：

• 签名人分布在不同地区和设备。
• 成员之间不存在同一控制关系。
• 定期检查并轮换离职或失效的签名人。
• 保存可验证的执行记录。
• 为紧急情况准备恢复和替补流程。

时间锁提供反应窗口

假设一项提案通过后要转走金库中的大量资产。如果操作立即执行，社区即使发现提案代码与描述不一致，也没有时间阻止。

时间锁把“决定已经通过”和“操作真正发生”分开，为审查和应急响应留出窗口。不过，面对正在发生的攻击，过长的时间锁又可能妨碍快速修复。

7. 案例一：协议参数治理

借贷和稳定币协议需要不断调整抵押率、利率、支持资产和风险上限。一种常见模式是让治理代币持有人或代表对参数变化投票。

抵押品调整案例

假设社区准备把一种新代币加入借贷协议：

1. 风险团队分析流动性、价格波动和预言机质量。
2. 提案设置抵押率、借款上限和清算参数。
3. 社区讨论该资产是否容易被操纵。
4. 正式投票通过后，时间锁等待审查。
5. 合约执行提案，把新资产加入市场。

如果参数过于宽松，攻击者可能利用低流动性资产借走优质资产；如果过于严格，新市场又无法使用。DAO 投票并不能取代风险专业知识，因此许多协议会设置专门的风险团队或委员会。

这类模式常见于 Maker、Aave、Compound 等协议治理。项目名称只是案例，不代表其当前具体参数或风险水平。

8. 案例二：ENS 的委托和工作组治理

ENS DAO 管理 ENS 协议和社区金库。其治理将代币投票、委托代表、章程与工作组结合起来。

一个普通代币持有人可能没有时间阅读每项提案，于是可以把投票权委托给长期参与治理的代表。代表研究提案并投票，持有人仍可以调整委托关系。

对于持续性的日常事务，工作组和负责人可以在授权预算内开展工作，例如生态建设、公共产品和治理运营。重大事项再进入更广泛的提案流程。

ENS 还使用章程为治理权设定边界：即使某个提案获得多数支持，也不意味着它一定符合组织的基本原则。

参考：ENS DAO 治理流程与 ENS DAO 章程

从案例中学到什么

• 委托解决“每个人都没有时间研究所有提案”的问题。
• 工作组适合处理需要连续投入的专业事务。
• 章程可以约束多数投票，防止治理无限扩张。
• 社会规则、法律主体与链上合约需要共同运作。

9. 案例三：Nouns DAO 的持续拍卖与公共金库

Nouns 采用一种容易观察的资金循环：系统持续生成并拍卖 NFT，拍卖收入进入 DAO 金库，NFT 持有人使用治理权决定如何使用资金。

假设社区成员提出制作一部开放版权短片：

1. 创作者公开脚本、预算和制作时间。
2. NFT 持有人讨论它是否有助于社区目标。
3. 符合条件的提案进入链上投票。
4. 通过后，金库按照提案执行资金转移。
5. 社区继续跟踪作品是否按计划交付。

它展示了 NFT 不仅可以作为收藏品，也能同时代表治理成员资格。但一枚 NFT 一票的设计，也意味着持有成本和资产集中会影响治理参与。

参考：Nouns DAO 机制介绍

从案例中学到什么

• 收入来源、成员资格与治理权可以通过协议连接起来。
• 链上执行提高了资金流的可验证性。
• 公开支出不等于支出有效，仍需要评审和验收。
• NFT 持有人与更广泛的社区参与者不一定拥有相同权力。

10. 案例四：紧急漏洞应该全民投票吗

假设安全团队发现一个尚未公开的漏洞，攻击者可能在两小时内转走资金。常规治理需要七天讨论和投票，显然来不及。

DAO 通常会考虑设置安全委员会，并授予有限权限，例如暂停特定合约。但这也产生新的问题：

• 委员会能否借“紧急”之名冻结正常用户？
• 权限是否有期限和适用范围？
• 暂停后由谁决定恢复？
• 委员身份和行动记录是否公开？

一种折中方案是让安全委员会只能暂停、不能转移资金，并要求暂停后在限定时间内获得完整治理确认，否则自动失效。

这个案例说明：治理越去中心化，紧急响应可能越慢；响应越集中，权力滥用风险越高。好的制度会限制紧急权力，而不是假设紧急权力永远不会被滥用。

11. DAO 常见的治理风险

低参与率

大量持有人不投票，少数活跃地址就可能决定结果。委托、提醒机制和合理的法定人数可以改善参与，但无法彻底解决冷漠问题。

巨鲸控制

代币加权投票可能让大户、团队和机构拥有决定性影响。公开委托、投票权上限或其他权重设计可以缓解，但也会增加复杂性。

治理攻击

攻击者可能购买或借入大量投票权，通过恶意提案转移资产或修改规则。提案门槛、历史快照、时间锁和安全否决机制可以提供防护。

多签失陷

签名人私钥泄露、合谋或长期不更新，会危及金库。硬件钱包、成员分散、密钥轮换和权限限制是必要措施。

治理疲劳

提案太多、文本太长或议题过于专业，会使普通成员退出治理。工作组和委托能够减少负担，但也可能让权力集中到少数专业参与者。

利益冲突

代表可能同时受雇于项目方、投资多个竞争协议，或从提案中直接获益。利益披露和回避机制对于建立信任十分重要。

12. DAO 不等于法律主体

智能合约能够持有资产和执行规则，但它本身不一定具有签订劳动合同、缴税、承担债务和出庭应诉的法律能力。

很多 DAO 会同时设立基金会、协会或公司，负责雇佣、知识产权、银行账户和合规事务。此时要区分：

• 链上治理决定了什么。
• 法律实体能够执行什么。
• 多签成员承担什么责任。
• 社区参与者是否构成合伙或其他法律关系。

不同地区对 DAO、代币和成员责任的规定差异很大。涉及募集资金、投资、雇佣或现实资产时，应获得适用地区的专业法律意见。

13. 如何判断一个 DAO 是否真正有效

不要只看它有没有治理代币或 Discord 社区，可以从以下维度评估：

1. 目标是否清楚：成员是否知道组织要解决什么问题。
2. 权力是否透明：合约管理员、多签成员和法律实体是否公开。
3. 参与是否真实：投票人数、委托分布和讨论质量如何。
4. 金库是否可持续：收入来源是什么，预算是否有监督。
5. 执行是否可靠：通过的提案能否按时交付和验收。
6. 安全是否分层：是否具有时间锁、权限限制和应急流程。
7. 退出是否明确：成员如何退出，资产和责任如何处理。

DAO 的价值不在于把“公司”换成“社区”，而在于能否用更透明、更开放的方式完成长期协作。

本文小结

• DAO 是技术规则与社会协作共同构成的在线组织形式。
• 一套完整治理包含讨论、提案、投票、时间锁、执行和监督。
• 一人一票、代币加权、委托和多签各有适用场景与缺点。
• 法定人数和提案门槛用于防止极少数成员控制决策。
• ENS 展示了委托、章程和工作组的组合治理。
• Nouns 展示了持续收入、NFT 成员资格和链上金库治理。
• 紧急权限能够提高响应速度，但必须限制范围和期限。
• 公开投票不能自动解决低参与率、巨鲸控制和利益冲突。
• DAO 不一定是法律主体，现实活动仍需要明确责任和合规安排。

真正的自治，不是取消所有负责人，而是让权力来源、决策过程、执行权限和问责方式都更加清楚。

下一篇：十一、Web3 监管：合规边界、常见风险与用户责任

监管内容变化很快。本篇提供的是理解框架和学习案例，不构成法律、税务或投资意见。进行交易、发行代币或经营相关业务前，应查询所在地监管机构的最新文件，并在必要时咨询专业人士。

1. 为什么 Web3 需要监管

区块链同时具有技术与金融属性。它可以改善跨境结算、资产登记和开放协作，也可能被用于诈骗、非法集资、洗钱、操纵市场和逃避制裁。

监管通常关注五个层面：

市场规则

防止虚假披露、内幕交易、操纵价格和未经许可募集资金，要求参与者在相对公平的信息环境中交易。

消费者保护

要求服务商说明风险、妥善保管客户资产、处理投诉，并避免用误导方式向不适合的用户推销高风险产品。

反洗钱与制裁

要求特定服务商识别客户、监测异常交易、保存记录，并在法律要求下报告可疑活动。

税务申报

买卖、兑换、支付、质押奖励、挖矿、空投和 NFT 交易，都可能产生记录或申报义务。是否纳税以及如何计算，取决于所在地规定和具体事实。

网络与托管安全

监管可能对客户资产隔离、私钥管理、审计、业务连续性和事件报告提出要求，降低平台倒闭或被攻击造成的损失。

2. 同一种代币可能面对不同规则

“加密货币”“治理代币”或“NFT”只是产品名称，并不能直接决定法律属性。监管者通常会查看发行方式、经济功能、持有人权利和实际营销方式。

支付型功能

如果资产主要用于转账或支付，可能涉及支付服务、反洗钱、外汇和资金传输规则。

投资属性

如果发行方公开募集资金，并让购买者期待依靠团队经营获得回报，可能触及证券、集体投资或金融产品规则。

使用权益

只能访问某个产品或服务的代币，也不一定自动排除金融监管。监管者会判断它是否真正投入使用，还是以“功能代币”名义进行投资募集。

稳定价值

锚定法币或其他资产的稳定币，可能受到储备、赎回、披露和发行人许可等额外要求。

NFT 与收藏品

真正独特、不可替代的收藏品可能适用不同规则。但把大量同质资产包装成 NFT，或以收益分配为卖点，仍可能进入金融监管范围。

一个“游戏金币”案例

项目把代币称为游戏金币，但在游戏上线前向公众出售，并宣传团队经营会推动价格上涨。即使名称强调“游戏”，监管判断仍可能关注它的融资方式和购买者预期。

反过来，一个已经运行的游戏积分，如果只能在封闭系统中兑换服务、不能自由交易，面对的规则可能完全不同。

3. KYC、AML 和转账信息规则

KYC 是什么

KYC 是“了解你的客户”。受监管平台通常会收集姓名、证件、地址或资金来源等信息，以确认账户由谁控制。

KYC 能提高违法活动追踪能力，但也让平台持有大量敏感数据。用户应同时关注服务商的数据保护、保存期限和泄露应对措施。

AML 是什么

AML 是反洗钱。服务商不仅要在开户时识别客户，还可能持续监测交易，识别资金分层、诈骗流入、受制裁地址和异常跨境活动。

Travel Rule 是什么

FATF 针对虚拟资产服务商推动转账信息规则。受监管服务商之间进行符合条件的转账时，可能需要传递发送方和接收方的必要信息。

身份信息通常由服务商之间通过合规渠道传递，并不意味着个人姓名直接公开写入区块链。区块链上主要显示地址、金额和时间等交易数据。

不同地区对适用门槛、信息字段和自托管钱包的处理方式可能不同，应以当地规则为准。

参考：FATF 虚拟资产与服务商风险方法指南

4. 去中心化不等于不受监管

一个协议可能没有传统账户系统，但仍然存在开发团队、网站运营者、前端、治理成员、手续费接收者和法律实体。

监管判断可能关注：

• 谁开发并持续控制协议。
• 谁能够升级合约或暂停交易。
• 谁收取费用并进行营销。
• 用户是否依赖某个前端或托管服务。
• 治理是否真正分散，还是由少数地址控制。

一个 DEX 案例

智能合约部署后可以自行撮合兑换，但官方网站仍由公司运营，公司还控制代币列表和管理员密钥。此时“合约去中心化”并不能直接回答前端经营者是否承担监管责任。

一个 DAO 案例

DAO 通过投票销售代币、雇佣推广人员并向公众承诺收益。即使没有注册公司，提案人、多签成员和实际运营者仍可能在特定地区承担责任。

5. 为什么不同地区会得出不同结论

Web3 交易可能同时连接用户所在地、平台所在地、发行方所在地和区块链节点所在地区。

分析时至少要确认：

1. 用户通常居住或纳税的地区。
2. 服务商在哪里注册、经营和主动营销。
3. 代币或产品具有什么实际功能。
4. 用户进行的是持有、兑换、发行、推广还是资产管理。
5. 法币与加密资产从哪里流入、流向哪里。

使用境外网站，不会自动绕开用户所在地的法律；平台能够访问，也不代表当地允许使用。

6. 中国内地：区块链技术与虚拟货币业务需要区分

中国内地政策支持区块链技术在实体经济和数字化中的合规应用，但对虚拟货币相关金融活动采取严格限制。

中国人民银行等部门 2021 年发布的通知明确指出：比特币、以太币、泰达币等虚拟货币不具有与法定货币等同的法律地位，相关兑换、交易中介、代币发行融资和衍生品等业务属于非法金融活动；境外交易所通过互联网向境内居民提供服务，也被纳入通知范围。

因此，“支持区块链创新”不能被理解为允许面向境内居民经营虚拟货币交易或发行融资业务。

个人还应注意：即使能够技术上访问某个协议或境外平台，也不代表交易受到法律保护。涉及代币交易、推广、支付结算、技术支持或为他人提供通道时，应先了解具体行为的法律风险。

参考：中国人民银行等部门《关于进一步防范和处置虚拟货币交易炒作风险的通知》

7. 中国香港：通过许可制度管理虚拟资产平台

香港对虚拟资产采取许可和持续监管框架。根据香港证监会公开资料，在香港经营或积极向香港投资者推广服务的中心化虚拟资产交易平台，需要符合相应许可要求。

普通用户需要区分三种状态：

• 已正式获得许可的平台。
• 正在申请但尚未获批的平台。
• 未受当地监管或没有相应许可的平台。

“已经申请”“正在审批”和“已经持牌”并不是同一回事。证监会也提醒，获得许可不代表监管机构保证平台的表现或信用。

核验时应直接使用 香港证监会虚拟资产交易平台名单，不要只相信平台自己的宣传截图。

8. 欧盟：MiCA 建立统一的加密资产框架

欧盟的《加密资产市场监管法案》通常简称 MiCA。它为不属于欧盟其他金融法规覆盖范围的加密资产发行和相关服务建立统一框架。

其关注对象包括部分加密资产发行人、稳定币发行人和加密资产服务商，并涉及授权、信息披露、组织管理、审慎要求和市场滥用等方面。

MiCA 并不代表所有加密资产都采用同一规则：已经属于传统金融工具的产品可能适用其他法律，真正独特且不可替代的资产也需要根据具体情况判断。

参考：欧盟委员会 MiCA 官方介绍

9. 美国：多机构和多层级规则并存

美国数字资产监管可能同时涉及联邦证券、商品、反洗钱、税务和州级许可等规则。某项资产或业务由哪个机构监管，往往取决于产品结构和实际活动。

对于普通用户，最容易忽视的是税务记录。美国国税局明确将数字资产范围涵盖加密货币、稳定币和 NFT，并要求符合条件的收入与处置交易进行申报。

这并不意味着其他国家采用相同税制，而是说明一个普遍原则：钱包之间可以自由转账，不代表税务义务自动消失。

参考：美国国税局数字资产指引

10. 托管平台与自托管的责任不同

使用托管平台

平台掌握私钥并维护账户系统，用户通常需要接受身份验证、提款审核和地区限制。相应地，平台可能承担客户资产保管、交易监测和监管报告义务。

持牌并不等于零风险。用户仍需查看资产是否隔离、平台如何处理破产、是否提供储备或审计信息，以及所在地区是否有赔偿机制。

使用自托管钱包

用户自己控制私钥，不依赖平台批准每笔链上交易。但用户也要自己承担助记词备份、合约授权、地址核验和税务记录责任。

自托管不等于匿名。公开区块链会长期保留地址之间的交易关系，一旦地址与现实身份关联，历史活动可能被分析。

11. 税务：没有换成法币也可能需要记录

不同地区的税务规则差异很大，但以下操作通常都值得完整记录：

• 用法币买入数字资产。
• 卖出或兑换为法币。
• 一种代币兑换另一种代币。
• 使用代币购买商品或服务。
• 获得质押、挖矿、空投或工作报酬。
• 铸造、购买和出售 NFT。
• 在不同钱包和平台之间转账。
• 支付网络手续费和平台费用。

一个兑换案例

用户用一种价值上涨的代币兑换稳定币，没有把钱提到银行账户。他可能认为自己“还没有兑现”，但某些地区会把代币交换视为资产处置，需要计算收益或损失。

一个钱包转账案例

把资产从自己的交易平台账户转到自己的钱包，通常与出售给他人不同。但如果缺少记录，未来可能难以证明两个地址都由自己控制，也难以还原取得成本。

最稳妥的做法是从第一笔交易开始保存时间、资产、数量、法币价值、手续费、交易哈希和交易目的。

12. 常见的合规误区

“平台能打开，所以一定合法”

网站没有屏蔽某个地区，不代表它获得当地许可，也不代表用户可以合法使用全部功能。

“只使用稳定币，所以没有税务问题”

稳定币仍然是数字资产。兑换、收益和支付可能产生报告或记录义务。

“链上没有实名，所以查不到”

地址虽然不是姓名，但交易关系公开可见。交易平台数据、银行记录和链上分析可能把地址与现实身份关联。

“DAO 投票通过，所以行为合法”

社区多数同意不能替代监管许可，也不能免除欺诈、制裁、税务或消费者保护责任。

“持牌平台一定不会倒闭”

许可代表平台受到一定规则约束，不是收益、流动性或信用保证。

“不知情收到风险资金就一定没事”

法律责任取决于事实和所在地规则，但资金来源异常可能导致平台审查、账户限制或调查。遇到陌生大额转入时，不应急于代为兑换或转出。

13. 普通用户的合规与记录清单

1. 核对当地规则：确认所在地是否允许使用该类资产和服务。
2. 核验平台资质：从监管机构官网查询，不依赖平台宣传。
3. 保存交易记录：记录买入、卖出、兑换、收益和转账。
4. 维护成本记录：保留取得时间、价格、手续费和资金来源。
5. 了解税务义务：确定哪些行为属于收入或处置，何时申报。
6. 保护身份和钱包：只向可信服务商提交资料，防止钓鱼和数据泄露。

如果准备发行代币、管理他人资产、提供兑换、代客操作或公开募集资金，应在开展业务前获得专业意见，而不是等产品上线后再补合规。

本文小结

• Web3 监管通常涉及市场规则、消费者保护、反洗钱、税务和托管安全。
• 代币的法律属性取决于实际功能、发行方式和所在地规则，而不是项目名称。
• KYC 用于识别客户，AML 用于持续监测风险，转账信息规则适用于部分受监管服务商。
• 去中心化协议仍可能存在可识别的开发、运营、治理和收费主体。
• 中国内地、香港、欧盟和美国采用不同监管结构，不能相互套用。
• 使用境外平台或自托管钱包，不会自动免除所在地的法律和税务责任。
• 持牌代表受到监管，不代表平台或资产绝对安全。
• 普通用户应长期保存交易、成本、手续费和钱包转移记录。

合规不是 Web3 的附加功能，而是使用数字资产时需要与钱包安全同时建立的基本习惯。

下一篇：十二、资产安全与风险管理：从防骗到交易纪律

本篇不提供价格预测或项目推荐，而是从用户需求、技术进展和商业模式出发，整理 Web3 值得长期观察的方向，以及个人可以如何参与。

1. 判断趋势的三个问题

看到一个新概念时，先不要问它会不会上涨，而要问：

1. 解决什么问题：没有区块链时，用户遇到了什么实际困难？
2. 为什么需要区块链：公开结算、自托管、可组合或抗单点故障是否真的重要？
3. 谁愿意付费：产品收入来自真实服务，还是主要依赖代币增发和新增参与者？

区块链是一种工具，而不是商业模式。技术成立，不代表市场需求成立；用户增长，也不代表收入能够覆盖成本。

2. 六个值得长期观察的方向

这些方向并不保证产生投资回报。它们值得关注，是因为背后存在可以持续验证的使用需求。

3. 趋势一：稳定币成为互联网结算工具

稳定币把法币计价单位带入区块链网络，使用户能够全天候转账，并与链上协议组合。

它可能适用于：

• 跨境企业之间的结算。
• 全球平台向创作者或自由职业者付款。
• 商户收款和供应商付款。
• 加密资产市场中的交易计价。
• 无法方便获得美元银行服务地区的数字结算。

案例：跨境自由职业者收款

假设设计师为海外客户完成项目：

1. 客户使用当地支付渠道购买合规发行的稳定币。
2. 稳定币通过支持的区块链发送给设计师。
3. 设计师可以保留稳定币、用于链上支付，或通过当地合规渠道兑换。

这个流程可能缩短结算路径，但没有消除风险。双方仍要考虑发行方信用、网络选择、兑换渠道、反洗钱、税务和当地法律。

Visa 等支付机构已经公开讨论并试验稳定币结算与支付能力，这说明稳定币正在从加密交易工具向支付基础设施延伸。参考：Visa 稳定币策略资料

长期观察指标

• 有多少交易来自真实支付，而不是交易平台内部调拨。
• 商户是否愿意接受并长期持有稳定币。
• 发行方储备和赎回机制是否透明。
• 用户是否能在不同网络和法币通道之间顺畅转换。
• 监管是否为发行和支付服务提供清晰规则。

4. 趋势二：现实世界资产上链

现实世界资产通常简称 RWA。它指的是把债券、基金份额、应收账款、商品或其他现实权益，通过数字代币进行登记、转移或结算。

资产上链不是把图片做成 NFT

一个有效的 RWA 系统至少需要连接五个环节：

链上代币只是其中一层。如果代币持有人没有清晰的法律权利，或者发行方无法交付底层资产，公开账本也无法自动解决问题。

案例：代币化短期债券基金

投资者完成身份验证后购买基金份额，份额以代币形式记录；基金管理人持有现实中的债券，托管人和审计机构核验资产；投资者按规则转让或赎回代币。

潜在优势包括缩短结算时间、提高可编程性和支持更细粒度的份额管理。主要风险则包括发行人、托管、法律执行、预言机、智能合约和流动性风险。

BIS 对代币化的讨论也强调，真正价值来自货币、资产和平台之间更顺畅的组合，而不仅是把已有资产换成链上形式。参考：BIS 关于现实资产代币化的资料

5. 趋势三：智能钱包降低使用门槛

传统钱包要求用户保管助记词、准备网络手续费，并逐笔理解授权和交易。这是大规模采用的重要障碍。

账户抽象和智能合约钱包尝试提供：

• 通过可信联系人或备用设备恢复账户。
• 为大额转账设置多重确认和等待时间。
• 一次完成授权与兑换等多步操作。
• 由应用赞助手续费，或使用其他代币支付费用。
• 为不同应用设置额度和有效期。

案例：带限额的家庭钱包

主账户可以设置三条规则：日常转账每天不超过一定额度；大额交易需要两台设备共同批准；主密钥丢失后，由三个恢复联系人中的两人帮助更换密钥。

这比“一个助记词控制全部资产”更接近日常金融账户体验。但智能钱包代码更复杂，也带来合约漏洞、恢复人合谋和服务依赖等新风险。

以太坊官方路线图将账户抽象视为改善钱包安全和体验的重要方向。参考：Ethereum.org 账户抽象介绍

6. 趋势四：扩容之后，重点转向互操作体验

Layer 2 和 Rollup 把大量交易集中处理，再把数据或结果提交到底层网络，从而降低成本并提高吞吐量。

扩容解决了一部分费用问题，也带来了新的碎片化：同一种资产分布在不同网络，用户需要跨链，应用需要处理不同确认规则和流动性。

未来体验是否改善，取决于钱包和应用能否把这些复杂性隐藏起来，同时保持安全边界清晰。

案例：一次跨网络购买

用户的稳定币在网络 A，想购买的 NFT 位于网络 B。理想体验是钱包自动选择安全路径、展示总费用并完成交易；现实中可能需要跨链桥、兑换手续费代币，再调用目标合约。

便利性越高，越要明确谁在执行跨链、资金经过哪些合约，以及失败后如何退款。

参考：Ethereum.org 扩容路线

7. 趋势五：可验证身份与隐私证明

今天的互联网身份通常被平台控制。用户更换平台时，很难带走账号、信誉和凭证。

DID 与可验证凭证提供另一种思路：机构签发可被密码学验证的凭证，用户自行保存，并在需要时向验证方出示。

案例：只证明“年满要求”

传统做法可能要求上传完整身份证。可验证凭证系统可以尝试只证明“年龄满足条件”，而不披露证件号码和详细生日。

案例：跨平台学历凭证

学校签发数字学历凭证，毕业生把凭证保存在自己的数字钱包中。申请工作时，雇主可以验证签发机构和凭证状态，而不必每次联系学校人工核实。

W3C 已发布 DID 标准，并持续推进可验证凭证相关规范。标准解决互操作问题，但现实采用仍依赖可信签发者、隐私设计和法律认可。参考：W3C DID 介绍

8. 趋势六：开放协议与链上组织

智能合约可以把支付、所有权和组织规则变成开放接口，让不同开发者在同一套协议上构建产品。

这可能形成类似互联网开放协议的创新模式：

• 开发者无需从零建立支付和资产系统。
• 用户可以在兼容应用间携带账户和资产。
• 社区通过公开提案资助工具和内容。
• 应用可以组合交易、借贷、身份和治理能力。

但“开放”不代表没有控制者。前端入口、管理员密钥、数据服务和品牌仍可能集中。判断开放程度，应看其他团队是否真的能够独立读取状态、运行客户端并构建替代产品。

9. 哪些方向仍需要保持谨慎

只依赖代币激励的产品

补贴可以帮助产品冷启动，却不能替代长期需求。如果用户只在奖励存在时使用，激励减少后活跃度可能快速下降。

没有明确法律权利的资产上链

链上记录透明，不等于现实资产归属能够执行。RWA 项目必须解释法律主体、托管、违约处理和赎回方式。

过度承诺的跨链互操作

跨链桥扩大了资产使用范围，也增加了合约、验证者和消息传递风险。所谓“一键跨链”只是隐藏操作步骤，不会消除底层风险。

把用户数量等同于真实采用

一个人可以创建多个钱包，空投和机器人也会制造大量地址。衡量产品时，应结合留存、手续费收入、真实支付和重复使用情况。

用价格证明技术价值

代币上涨可能来自流动性和市场情绪，不能证明协议具有长期需求；价格下跌也不一定意味着技术完全无用。产品价值与资产价格需要分别分析。

10. 普通人有哪些参与路径

Web3 的机会不只等于购买代币。投入时间学习、参与开源项目或提供专业服务，也是一种参与。

技术与产品

• 智能合约和协议开发。
• 钱包、前端和移动端体验。
• 数据索引、节点与开发者工具。
• 安全审计、测试和事件响应。
• 产品研究和用户体验设计。

运营与内容

• 技术文档与开发者教育。
• 社区运营和治理协调。
• 多语言本地化。
• 用户研究和客户支持。
• 品牌、设计与内容传播。

金融、法律与数据

• 链上数据分析和风险监控。
• 稳定币支付与结算运营。
• 会计、税务和合规研究。
• 协议风险、经济模型与治理分析。

一个 Web2 产品经理转型案例

产品经理不必先学会编写智能合约。可以选择一个钱包完成转账、兑换和授权，记录每一步困惑，再研究交易生命周期和安全边界，最后为开源项目提交产品改进建议。

行业能力建立在原有职业能力之上，而不是把过去经验全部清零。

11. 建立自己的 Web3 学习项目

相比只看资讯，完成一个可验证作品更有价值。

可以选择以下项目：

• 建立一个测试网钱包并记录完整安全流程。
• 分析一个协议的资金路径、权限与风险。
• 制作一份稳定币转账网络对比表。
• 阅读并解释一项 DAO 提案。
• 为开源项目修正文档或翻译内容。
• 使用公开链上数据制作简单看板。
• 写一篇某个安全事件的复盘报告。

作品能够证明你会查资料、理解机制并清楚表达，比简历里写“熟悉 Web3”更有说服力。

12. 如何判断项目是否值得长期关注

可以使用下面的研究框架：

| 维度 | 核心问题 |
|

资产安全不是记住“不要泄露助记词”这一句话，而是建立多层防护，让一次点击错误、一个设备故障或一个平台问题不会影响全部资产。

本篇讨论安全与风险管理，不构成任何投资建议。

1. 安全是一套系统，不是某个工具

硬件钱包不能阻止用户确认恶意交易，双重验证也不能保护已经泄露的助记词。每一种工具只解决一部分问题。

完整的个人防线通常包括：

• 设备安全：操作系统、应用来源、浏览器扩展和网络环境。
• 账户安全：邮箱、交易平台、云盘和社交账号的密码与多重验证。
• 钱包安全：私钥、助记词、备份和恢复方式。
• 交易核验：域名、网络、合约、金额、授权和签名内容。
• 资产分层：不同钱包、平台与用途之间的风险隔离。

安全的目标不是保证永远不出错，而是降低出错概率，并限制单次错误的最大影响。

2. 先建立自己的威胁模型

威胁模型就是提前思考：我的资产可能通过什么方式损失？

常见风险可以分为五类：

| 风险类型 | 典型场景 | 主要防护 |
|

理解二者，是理解整个加密行业最重要的一步。

1. 比特币为什么会出现

传统电子支付依赖银行、支付机构和清算网络维护账本。系统运转高效，但用户必须相信中介正确记账、不会随意冻结交易，并能持续提供服务。

比特币提出另一条路线：让分布在全球的节点共同维护一份公开账本，用密码学签名证明资产所有权，用工作量证明决定交易历史，从而在没有中央记账人的情况下防止同一笔钱被重复花费。

比特币白皮书将其描述为点对点电子现金系统。它最重要的创新并不是创造一串数字，而是组合已有技术，建立一套公开、可验证且难以篡改的价值转移规则。参考：Bitcoin 白皮书

2. UTXO：比特币怎样记录余额

比特币没有直接在账本里写“某地址拥有 1 BTC”，而是记录尚未花费的交易输出，即 UTXO。

可以把 UTXO 理解成不同面额的数字钞票：

• 收到一笔比特币，会产生一个可以被你花费的输出。
• 发起付款时，钱包选择一个或多个输出作为输入。
• 输入总额大于付款金额时，剩余部分会作为找零形成新的输出。
• 已经作为输入使用的 UTXO 不能再次使用。

例如，小林拥有 0.3 BTC 和 0.8 BTC 两个 UTXO。支付 0.9 BTC 时，钱包可能同时花费二者，并创建“收款人 0.9 BTC”和“找零减去手续费”两个新输出。

3. 工作量证明如何形成共识

比特币矿工把待确认交易组合成候选区块，并投入计算寻找符合网络难度要求的哈希结果。最先找到有效结果的矿工广播区块，其他节点独立验证其中每笔交易和区块规则。

工作量证明承担三个作用：

1. 让创建新区块需要付出现实成本。
2. 让节点能够依据累计工作量选择交易历史。
3. 通过区块奖励和手续费激励参与者保护网络。

矿工不能随意修改供应上限或创造不符合规则的交易。完整节点会验证区块，拒绝违反共识规则的数据。Bitcoin Core 的说明也强调，独立验证能够阻止矿工让节点接受违反供应限制的区块。参考：Bitcoin Core 验证机制

4. 供应上限、减半与安全预算

比特币协议将最终供应量限制在约 2,100 万枚。新区块奖励会按预定规则周期性减半，因此新增供应速度逐渐下降。

这不等于价格必然上涨。价格仍然取决于需求、流动性、监管环境和市场预期。减半直接改变的是新增供应节奏，不是市场必须接受的价格。

随着区块补贴下降，交易手续费在网络安全激励中的相对重要性可能提升。这也是研究比特币长期运行时必须关注的问题。

5. 以太坊为什么不只是另一种货币

比特币的脚本能力有意保持相对克制。以太坊则希望让开发者在区块链上部署通用程序，也就是智能合约。

以太坊可以被理解为一台由全球节点共同验证的状态机：

• 账户保存余额、代码和状态。
• 用户发送带签名的交易。
• EVM 按统一规则执行合约代码。
• 每个节点验证执行结果。
• 合法结果更新为新的全网状态。

Ethereum.org 将 EVM 描述为所有以太坊节点一致执行代码的去中心化虚拟环境。参考：Ethereum Virtual Machine

6. 智能合约能做什么

智能合约是部署在链上的程序。满足调用条件后，它按照代码执行，不需要传统服务器管理员逐笔批准。

常见应用包括：

• 去中心化交易和借贷。
• 稳定币与代币发行。
• NFT、游戏资产和会员凭证。
• DAO 投票与链上金库。
• 保险、预测市场和现实资产登记。

“自动执行”不代表“不会出错”。漏洞、权限设计、预言机数据和治理决策都可能影响结果。代码公开也不意味着普通用户已经完成审计。

7. ETH 在系统中的作用

ETH 不只是交易标的，它在以太坊网络中承担多项功能：

• 支付交易和智能合约执行所需的 Gas。
• 作为 DeFi 中的抵押品和基础资产。
• 由验证者质押以参与共识并承担惩罚风险。
• 为链上应用提供统一的原生结算资产。

以太坊目前采用权益证明。验证者质押 ETH、提出或证明区块，诚实参与获得奖励，严重违反规则可能遭受罚没。

8. BTC 与 ETH 的关键差异

| 维度 | 比特币 | 以太坊 |
|

1. 交易究竟是什么

交易是账户发给区块链的一条带签名指令。它可以是转账，也可以是调用合约、授权代币或部署程序。

以太坊交易通常包含：

| 字段 | 作用 |
|

本文用于建立研究框架，不构成任何投资建议。

1. Coin 与 Token 的区别

Coin 通常是某条区块链的原生资产，例如 BTC 和 ETH，用于支付网络费用、奖励维护者或保障共识。

Token 通常由智能合约发行，依赖已有公链运行，例如以太坊上的 ERC-20 代币。它可以表示治理权、协议权益、稳定价值、游戏资源或现实资产凭证。

这种划分不是价值高低判断。关键问题是：代币在系统中是否真正必要，以及持有者具体拥有什么权利。

2. 先分清四种供应量

| 指标 | 含义 |
|

在选择路径前，先回答三个问题：收益由谁支付、为什么愿意支付、最坏情况下会损失什么。

本文用于知识学习和风险教育，不构成投资、交易或法律建议。

1. 先分清四种收益来源

资产收益

通过低价买入、高价卖出获得价差，例如长期持有 BTC、ETH 或其他代币。收益来自未来购买者愿意支付更高价格，并不产生确定现金流。

协议收益

通过质押、借贷、提供流动性或运行节点获得奖励。收益可能来自用户手续费，也可能来自代币增发和短期补贴。

劳动收益

通过研究、开发、设计、翻译、内容创作、社群管理和商务拓展获得报酬。这类收入主要依赖个人能力和交付结果。

经营收益

通过运营媒体、工具、社群、咨询业务或产品获得订阅费、服务费、广告费和销售收入，需要面对获客、成本、合规与持续经营风险。

理解收益来源，可以避免把“领取项目补贴”误认为稳定利润，也能看清高收益背后究竟承担了什么风险。

2. 买币囤币：用时间换取行业增长

买币囤币是最容易理解的路径：研究资产后分批买入，并在较长周期内持有。

收益从哪里来

• 网络使用和市场需求增长。
• 资产稀缺性得到更多人认可。
• 行业周期、流动性和风险偏好推动估值提高。

适合什么人

• 有稳定现金流，不依赖短期变现。
• 能承受较大浮亏和多年波动。
• 愿意研究资产、托管方式与退出条件。

常见方法

一次性买入适合已经完成研究、能够接受入场时点风险的人。

定期定额可以降低择时压力，但不会消除资产长期下跌或归零风险。

核心与观察仓是把多数资金放在研究较充分、流动性较好的资产中，只用少量资金验证高风险判断。

主要风险

• 买入没有真实需求或价值捕获的代币。
• 高位追涨后无法承受回撤。
• 过度集中于单一资产、平台或叙事。
• 私钥泄露、平台破产和监管限制。
• 没有退出计划，把长期持有变成拒绝止损。

CFTC 提醒，数字资产价格由市场供需驱动，可能出现剧烈波动，平台还存在操纵、网络安全和客户保护不足等风险。参考：CFTC 虚拟货币交易风险提示

3. 现货波段：用判断和纪律获取价差

现货交易不使用借贷杠杆，交易者通过趋势、区间或事件变化买卖资产。

一次完整交易至少需要写清：

交易理由 + 入场条件 + 仓位大小 + 失效条件 + 退出计划

例如，不能只写“突破就买”，而应说明观察周期、有效突破标准、允许损失、分批方式，以及判断错误时如何退出。

现货不会因为短期波动被平台强制平仓，但资产仍可能大幅下跌。频繁交易还会产生手续费、滑点、税务记录和心理消耗。

4. 合约交易：收益与损失都会被放大

永续合约、期货和期权允许交易者做多、做空或使用杠杆。它们原本可以用于套期保值，但也经常被当作高风险投机工具。

杠杆是怎样放大结果的

假设使用 1,000 USDT 保证金建立 10,000 USDT 的仓位：

• 标的上涨 3%，仓位浮盈约 300 USDT，未计费用。
• 标的下跌 3%，仓位浮亏约 300 USDT。
• 当亏损接近平台维持保证金要求时，仓位可能被强制平仓。

杠杆并没有提高判断准确率，只是让错误更快、更昂贵。

还需要承担哪些成本

• 开仓与平仓手续费。
• 买卖价差和滑点。
• 永续合约资金费率。
• 剧烈波动时的强平与穿仓风险。
• 平台宕机、标记价格和对手方风险。

CFTC 明确提醒，保证金和杠杆会放大现货价格波动的影响，投机性期货交易属于高风险行为。参考：CFTC 杠杆风险说明

新手应遵守的底线

• 在稳定盈利能力得到长期验证前，不把高杠杆当作主要路径。
• 单笔最大损失必须事先确定，不能通过不断补保证金回避错误。
• 不借生活费、应急资金或负债资金交易。
• 不相信带单、喊单、保本套利和自动盈利机器人。

5. 撸空投：用时间、资金与链上行为换取不确定激励

空投通常用于奖励早期用户、分配治理权或推广网络。参与者通过测试产品、跨链、交易、提供流动性、投票或完成社区任务，争取未来可能发放的代币。

收益从哪里来

主要来自项目预留的社区代币，而不是链上操作本身自动创造利润。

需要投入什么

• 研究项目和规则的时间。
• Gas、跨链和交易成本。
• 承担合约、桥、资产和钱包安全风险。
• 保存记录并持续使用产品。

一个正确的成本表

| 项目 | 应记录内容 |
|

这个领域既有真实运行的基础设施，也有仍在探索的产品；既包含技术创新，也伴随着投机、欺诈和安全风险。因此，学习 Web3 的第一步不是寻找“下一个机会”，而是建立一套能够分辨概念、事实和宣传的知识框架。

为什么需要系统学习

刚接触 Web3 时，你可能会遇到大量陌生词汇：公链、钱包、Gas、智能合约、DeFi、NFT、DAO、Layer 2……如果只是零散地记住这些词，很容易知道得不少，却无法解释它们之间的关系。

系统学习主要解决四个问题：

1. 理解系统如何运作：一笔交易如何发出、验证和记录，钱包与区块链分别承担什么角色。
2. 看懂不同应用：DeFi、稳定币、NFT 和 DAO 解决什么问题，又引入了哪些新风险。
3. 建立判断能力：面对新项目时，能够检查它的技术、需求、经济模型、团队和安全边界。
4. 保护个人资产：理解私钥、授权、钓鱼、合约漏洞和平台风险，避免因基础错误造成损失。

这一章会学到什么

本章从基础概念开始，逐步建立 Web3 的整体地图：

• Web3 与传统互联网有什么不同；
• 区块链、公链和智能合约如何协作；
• 身份、钱包和数字资产之间是什么关系；
• DeFi、稳定币、NFT、GameFi 与 DAO 的基本逻辑；
• 不同地区为什么采用不同的监管方式；
• 普通人可以通过哪些方向参与这个行业；
• 如何识别资产安全、平台和市场风险。

这些内容的目标不是让你记住所有名词，而是帮助你回答三个问题：它是什么、为什么存在、使用它需要承担什么风险。

推荐的学习方式

第一次阅读：建立地图

按侧边栏顺序阅读，先理解各主题之间的联系。遇到不熟悉的词，可以暂时记录下来，不必在第一次阅读时追求所有细节。

第二次阅读：动手验证

结合区块浏览器、官方文档和公开数据验证文中的概念。例如观察一笔链上交易包含哪些信息，或比较不同网络的费用与确认方式。

第三次阅读：形成自己的笔记

每学完一个主题，尝试用自己的话回答：

• 它解决了什么问题？
• 它依赖哪些技术或参与者？
• 它和传统方案相比有什么变化？
• 哪些情况下可能失效？
• 对普通用户最大的风险是什么？

如果无法清楚回答，就说明这个概念仍需要继续查证。

区分技术、产品和资产

学习过程中要特别注意：认可一项技术，不等于认可所有基于它发行的资产；理解一个产品，也不代表它适合投资。

可以把判断拆成三个层次：

| 层次 | 关注的问题 |
|

第一章：Web3 基础与行业全景，by LinkJM

写在前面

Web3常用名词&术语

一、Web3 是什么：从互联网演进到用户主权

二、比特币与以太坊：数字货币与可编程区块链

三、Web3 技术框架：区块链、公链与扩容

四、数字身份与钱包：地址、私钥和账户安全

五、链上交易全过程：签名、Gas 与区块确认

六、代币经济学：供应、解锁与价值捕获

应用生态

七、DeFi 与稳定币：开放金融的机制与风险

八、NFT：数字所有权、应用场景与常见风险

九、GameFi：链上游戏、资产经济与可持续性

十、DAO：链上协作、治理机制与现实边界

参与边界

十一、Web3 监管：合规边界、常见风险与用户责任

十二、资产安全与风险管理：从防骗到交易纪律

十三、Web3 赚钱路径：从资产收益到技能变现

总结与展望

十四、Web3 的未来：真实需求、行业趋势与参与机会

提示

最近在做SEO，因为链接没有做同步，需要清除之前旧站的链接，重新提交，让搜索引擎尽快索引，google search console的已经基本做差不多了

bing最近因为 New Bing 的原因也用的比较多，所以做了一些工作，很方便的是，它可以直接同步GSC的站点数据，不过就只是域数据，URL还是要自己提交

为了尽快索引，只提交sitemap是不够的，还需要调用API手动提交URL

官方示例

python代码

解读

在上面的脚本中，我们首先指定了Sitemap的URL。然后，我们使用Python中的requests库获取Sitemap的内容，并使用Python中的xml.etree.ElementTree库解析Sitemap中的URL。

接下来，我们使用Bing API提交URL。我们首先指定Bing API的密钥和API URL，并设置请求头。然后，我们将Sitemap中提取的URL列表作为数据，将其作为JSON格式发送到Bing API。最后，我们检查响应的状态码，以确保URL已成功提交。

注意：在使用Bing API提交URL之前，需要先注册Bing Webmaster工具，并获取Bing API密钥。还需要将"https://example.com"替换为自己的站点URL。

API密钥生成↘️

1. 访问Bing Webmaster Tools
2. 右上角设置


相关信息

这是一个利用GitHub Actions自动触发的工作流进行解析更新的url并推送到搜索引擎的python脚本,除了之前介绍过的bing api之外，还增加了百度和Google的相关内容

关于GitHub Actions的介绍可以看这里👉GitHub Actions

这个脚本也可以集成到 GitHub Actions，在网站更新后自动执行 URL 提交任务。

流程图

提示

之前介绍了ZSH的安装和使用，这次把最终成果介绍一下，就是ZSH + iTerm2 + Pure

前置工作：安装ZSH，请参照之前的文章👉zsh安装

目录

先看效果图

安装pure

👉官方文档

可以使用 npm 或手动安装。需要 Git 2.15.2+ 和 ZSH 5.2+。已知旧版本的 ZSH 可以工作，但不推荐使用。

如果是手动安装的，将克隆的 repo 的路径添加到 $HOME/.zshrc 中的 $fpath 。

# .zshrc
fpath+=($HOME/.zsh/pure)

将以下内容复制到 .zshrc文件中

autoload -U promptinit; promptinit
prompt pure

在 .zshrc 中设置 ZSH_THEME="" 以禁用 oh-my-zsh 主题。

到这里就基本完成了，如果要基于pure做详细定制，请参考文档

iTerm2

👉戳这里下载 官方下载地址

效果图我自用的配置文件在这里 👉 链接 密码:74aq

1.主题配置

访问iTerm2主题网站👉iTerm2-Color-Schemes

可以下载zip包并解压到本地，进入解压缩的文件目录，找到schemes文件夹，里边全是主题配置，可以对照github上的效果图来选择

2. 标签页配色

标签配色默认为黑色，不能与操作页面保持统一

打开iTerm2，打开Preferences配置界面，Appearence -> General，将 Theme 改为 Minimal

3. 设置 Status bar

iTerm2 提供了不少的 Status bar，开启后我们可以在终端的最上方非常方便的实时查看本机的一些信息。

打开iTerm2，打开Preferences配置界面，Profiles -> session-> 勾选 Status bar enable-> configure Status bar，选择自己想要的展示内容即可。向下托动放入Active Components 中即可,我这里只选了CPU、内存、网络

4. 光标选择

iterm提供了三种光标可供选择：_、|、[]。

打开iTerm2，打开Preferences配置界面，Profiles -> text-> cursor，选择自己想要的光标即可。

5.配置SSH快速连接

#首先在/Users目录下按照如下命令创建sh脚本
cd /Users/

#创建iterm文件夹
mkdir iterm
 
#进入iterm文件夹
cd iterm

#创建myserver.sh文件
touch myserver.sh

#编辑myserver.sh文件
vi myserver.sh

如果出现没有权限，就命令前面加上sudo

键盘输入i编辑文件，插入以下内容：

#!/usr/bin/expect
set timeout 30
spawn ssh -p [lindex $argv 0] [lindex $argv 1]@[lindex $argv 2]
expect {
        "(yes/no)?"
        {send "yes\n";exp_continue}
        "password:"
        {send "[lindex $argv 3]\n"}
}
interact

myserver.sh文件中变量解释：

[lindex $argv 0]：端口号
[lindex $argv 1]：服务器用户名
[lindex $argv 2]：服务器IP地址
[lindex $argv 3]：服务器密码

插入完成后键盘esc 然后输入:wq退出，接下来给文件赋权

chmod 777 myserver.sh
打开iTerm2，打开Preferences配置界面，Profiles -> general，左下角点击+号，新建profile，参考下面图片在对应位置输入内容即可。

Name:根据需求输入，通常选择标识性较强的内容便于区分，例如服务器的IP地址

Command：这里选择login Shell

Send text at start ：填写格式形如A B C D E这样，每一个部分之间用空格隔开，根据自己实际情况填写,下面是对每一部分内容的解释

结语

当然这里只介绍一部分，还有很多高级玩法，需要用到的时候自己去研究一下了

This document is not completed and will be updated anytime.

Catagory

• Catagory
• Unix
• Unix-like
  • Single UNIX Specification
  • Apple iOS
  • XNU Kernel
• Linux
  • Linux Kernel
  • GNU Project
  • Android
  • Android Kernel
  • Android ROM
  • Chrome OS
  • Chromium OS

MacOS 自带的 bash 作为几乎所有 Linux 发行版的默认终端，正常使用时没什么问题的

这里介绍一个更强大的终端神器

目录

背景介绍

在 unix 内核的操作系统中,当然现在衍生出好多分支,linux ,OS X 都算.

shell 就算和上面这些系统内核指令打交道的一座桥梁,我们通过键盘输入一种自己容易记忆识别的符号标识(shell 命令)

然后 shell 解析这种命令再反馈给内核去执行一系列操作.

zsh 和 shell 有什么关系呢?

其实 zsh 也是一种 shell ,但是并不是我们系统默认的 shell ,unix 衍生系统的默认 shell 都是 bash。

查看已安装 shell
查看 Mac 上已有的 shell,一共有 6 种

Rust 最早是 Mozilla 雇员 Graydon Hoare 的个人项目。从 2009 年开始，得到了 Mozilla 研究院的资助，2010 年项目对外公布，2010 ～ 2011 年间实现自举。自此以后，Rust 在部分重构 -> 崩溃的边缘反复横跳（历程极其艰辛），终于，在 2015 年 5 月 15 日发布 1.0 版。

在紧锣密鼓的开发过程中，Rust 建立了一个强大且活跃的社区，形成一整套完善稳定的项目贡献机制（Rust 能够飞速发展，与这一点密不可分）。Rust 现在由 Rust 项目开发者社区 维护， Rust 基金会赞助支持。

大家可能疑惑 Rust 为啥用了这么久才到 1.0 版本？与之相比，Go 语言 2009 年发布，却在 2012 年仅用 3 年就发布了 1.0 版本。

• 首先，Rust 语言特性较为复杂，所以需要全盘考虑的问题非常多；
• 其次，Rust 当时的参与者太多，七嘴八舌的声音很多，众口难调，而 Rust 开发团队又非常重视社区的意见；
• 最后，一旦 1.0 快速发布，那绝大部分语言特性就无法再被修改，对于有完美强迫症的 Rust 开发者团队来说，某种程度上的不完美是不可接受的。

因此，Rust 语言用了足足 6 年时间，才发布了尽善尽美的 1.0 版本。

为何又来一门新语言？

简而言之，因为还缺一门无 GC 且无需手动内存管理、性能高、工程性强、语言级安全性以及能同时得到工程派和学院派认可的语言，而 Rust 就是这样的语言。你也可以回忆下熟悉的语言，看是不是有另外一门可以同时满足这些需求：)

至于 Rust 最为人诟病的点，那也就一个：学习曲线陡峭。不过当语言生态起来后，这都不算问题。

缓解内卷

有人说 Rust 作为新语言会增加内卷，其实恰恰相反，Rust 可以缓解内卷。为何不说 C++ 内卷，而说 Java、Python、JS 内卷？不就是后几个相对简单、上手容易嘛？而 Rust 怎么看也是 C++ 级别的上手难度。

其实从我内心不可告人的角度出发，并不希望 Rust 大众化，因为这样可以保饭碗、保薪资，还能拥有行业内的地位。但是从对 Rust 的喜爱角度出发，我还是希望能卷一些。不过，目前来看真的卷不动，现在全世界范围内 Rust 的需求都大于供给，特别是优秀的 Rust 程序员更是难寻。

与 Go 语言相比，成为一名优秀的 Rust 程序员所需的门槛高得多，例如融汇贯通 Rust 语言各种中高级特性、闭着眼睛趟过各种坑、不用回忆无需查找就能立刻写出最合适的包/模块/方法、性能/安全/工程性的权衡选择信手拈来、深层性能优化易如反掌、异步编程小菜一碟，更别说 Rust 之外的操作系统、网络、算法等等相关知识。

所以，Rust 可以缓解内卷，而不是增加内卷。可以说是程序员的福音，不再是被随意替换的螺丝钉。

运行效率

得益于各种零开销抽象、深入到底层的优化潜力、优质的标准库和第三方库实现，Rust 具备非常优秀的性能，和 C、C++ 是 一个级别。

同时 Rust 有一个极大的优点：只要按照正确的方式使用 Rust，无需性能优化，就能有非常优秀的表现，不可谓不惊艳。

现在有不少用 Rust 重写的工具、平台都超过了原来用 C、C++ 实现的版本，将老前辈拍死在沙滩上，俨然成为一种潮流～～

开发效率

Rust 的开发效率可以用先抑后扬来形容。在最初上手写项目时，你的开发速度将显著慢于 Go、Java 等语言，不过，一旦开始熟悉标准库、熟悉生命周期和所有权的常用解决方法，开发效率将大幅提升，甚至当形成肌肉记忆后，开发效率将不会慢于这些语言，而且原生就能写出高质量、安全、高效的代码，可以说中高级 Rust 程序员就是高效程序员的代名词。

开源

目前 Rust 的主战场是在开源上，Go 的成功也证明了农村包围城市( 开源包围商业 )的可行性。

• UI 层开发，Rust 的 WASM 发展的如火如荼，隐隐有王者风范，在 JS 的基础设施领域，Rust 也是如鱼得水，例如 swc、 deno 等。同时 nextjs 也是押宝 Rust，可以说 Rust 在前端的成功完全是无心插柳柳成荫。
• 基础设施层、数据库、搜索引擎、网络设施、云原生等都在出现 Rust 的身影，而且还不少。
• 系统开发，目前 Linux 已经将 Rust 语言纳入内核，是继 C 语言后第二门支持内核开发的语言，不过刚开始将主要支持驱动开发。
• 系统工具，现在最流行的就是用 Rust 重写之前 C、C++ 写的一票系统工具，还都获得了挺高的关注和很好的效果，例如 sd, exa, ripgrep, fd, bat 等。
• 操作系统，正在使用 Rust 开发的操作系统有好几个，其中最有名的可能就是谷歌的 Fuchsia，Rust 在其中扮演非常重要的角色。
• 区块链，如果 Rust 的份额说第二，应该没人敢稳说自己是第一吧？

类似的还有很多，我们就不一一列举。总之，现在有大量的项目正在被 Rust 重写，同时还有海量的项目在等待被重写，这些都是赚取github 星星和认可的好机会。在其它语言杀成一片红海时，Rust 还留了一大片蓝海等待大家的探索！

相比其他语言 Rust 的优势

由于篇幅有限，我们这里不会讲述详细的对比，就是简单介绍下 Rust 的优势，并不是说 Rust 优于这些语言，大家轻喷：)

Go

Rust 语言表达能力更强，性能更高。同时线程安全方面 Rust 也更强，不容易写出错误的代码。包管理 Rust 也更好，Go 虽然在 1.10 版本后提供了包管理，但是目前还比不上 Rust 。

C++

Rust 与 C++ 的性能旗鼓相当，但是在安全性方面 Rust 会更优，特别是使用第三方库时，Rust 的严格要求会让三方库的质量明显高很多。

语言本身的学习，Rust 的前中期学习曲线会更陡峭，但是在实际的项目开发过程中，C++ 会更难，代码也更难以维护。

Java

除了极少数纯粹的数字计算性能，Rust 的性能全面领先于 Java 。同时 Rust 占用内存小的多，因此实现同等规模的服务，Rust 所需的硬件成本会显著降低。

Python

性能自然是 Rust 完胜，同时 Rust 对运行环境要求较低，这两点差不多就足够抉择了。不过 Python 和 Rust 的彼此适用面其实也不太冲突。

使用现状

• AWS 从 2017 年开始就用 Rust 实现了无服务器计算平台： AWS Lambda 和 AWS Fargate，并且用 Rust 重写了 Bottlerocket OS 和 AWS Nitro 系统，这两个是弹性计算云 (EC2) 的重要服务
• Cloudflare 是 Rust 的重度用户，DNS、无服务计算、网络包监控等基础设施都与 Rust 密不可分
• Dropbox 的底层存储服务完全由 Rust 重写，达到了数万 PB 的规模
• Google 除了在安卓系统的部分模块中使用 Rust 外，还在它最新的操作系统 Fuchsia 中重度使用 Rust
• Facebook 使用 Rust 来增强自己的网页端、移动端和 API 服务的性能，同时还写了 Hack 编程语言的虚拟机
• Microsoft 使用 Rust 为 Azure 平台提供一些组件，其中包括 IoT 的核心服务
• GitHub 和 npmjs.com，使用 Rust 提供高达每天 13 亿次的 npm 包下载
• Rust 目前已经成为全世界区块链平台的首选开发语言
• TiDB，国内最有名的开源分布式数据库

尤其值得一提的是，AWS 实际上在押宝 Rust，内部对 Rust 的使用已经上升到头等公民 first-class 的地位。

Rust 语言版本更新

与其它语言相比，Rust 的更新迭代较为频繁（得益于精心设计过的发布流程以及 Rust 语言开发者团队的严格管理）：

• 每 6 周发布一个迭代版本
• 2-3 年发布一个新的大版本，例如 Rust 2018 edition，Rust 2021 edition

好处在于，可以满足不同的用户群体的需求：

• 对于活跃的 Rust 用户，他们总是能很快获取到新的语言内容，毕竟，尝鲜是技术爱好者的共同特点：)
• 对于一般的用户，edition 大版本的发布会告诉他们：Rust 语言相比上次大版本发布，有了重大的改进，值得一看
• 对于 Rust 语言开发者，可以让他们的工作成果更快的被世人所知，不必锦衣夜行

总结

连续 6 年最受欢迎的语言当然不是浪得虚名。 无 GC、效率高、工程性强、强安全性以及能同时得到工程派和学院派认可，这些令 Rust 拥有了自己的特色和生存空间。社区的友善，生态的快速发展，大公司的重仓跟进，一切的一切都在说明 Rust 的璀璨未来。

当然，语言毕竟只是工具，我们不能神话它，但是可以给它一个机会，也许，你最终能收获自己的真爱 ：)

相信大家听了这么多 Rust 的优点，已经迫不及待想要开始学习旅程，那么容我引用一句 CS（Counter-Strike：反恐精英） 的经典台词：Ok, Let's Rust.

引自：Rust语言圣经(Rust Course)

当浏览器的网络线程收到 HTML 文档后，会产生一个渲染任务，并将其传递给渲染主线程的消息队列。

在事件循环机制的作用下，渲染主线程取出消息队列中的渲染任务，开启渲染流程。

嘿~
:cakecake: 播放器有了，撒花✿✿ヽ(°▽°)ノ✿:tadatada:

文档👉🏻戳这里文档

介绍

借鉴了vuepress-plugin-sbaudio和vuepress-plugin-meting 在此表示感谢

借鉴MetingJS解析和使用APlayer作为播放组件

安装很方便

使用也很方便

plugins: [
    metingPlugin({
      metingOptions: {
        global:true, // 开启关闭全局播放器
        server: "tencent",
        api: "https://api.injahow.cn/meting/?server=:server&type=:type&id=:id&auth=:auth&r=:r",
        type: "playlist",
        mid: "851947617",
      },
    }),
];

可作为组件引入

也可作为全局播放器引入

全局引入目前和看板娘有些重叠，还没有处理，先把开关关了

GitHub Actions 是什么？

Github Actions 是 Github 官方出的持续集成服务, 挺早之前就推出了。类似的还有如微软的DevOps、GitLab CI、Circle CI、Travis CI等等。大家知道，持续集成由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作就称为 actions。

很多操作在不同项目里面是类似的，完全可以共享。GitHub 注意到了这一点，想出了一个很妙的点子，允许开发者把每个操作写成独立的脚本文件，存放到代码仓库，使得其他开发者可以引用。

如果你需要某个 action，不必自己写复杂的脚本，直接引用他人写好的 action 即可，整个持续集成过程，就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。

什么是CI/CD？

What is CI/CD? (redhat.com)

字面意思就是持续集成Continuous Intergation/持续分发Continuous Delivery持续部署Continuous Deployment，网上有太多同质的解释都太过于晦涩，

提到CI/CD就离不开一个词叫流水线。流水线上每个人的工作是分工明确的，而且工程是有先后顺序，就像造一台车，先造零件，然后组装、喷涂、内饰最后还要测试。软件开发同样如此，有前期的产品设计，UI设计、单元的开发，产品的测试，优化迭代等都由不同的人负责。

生成 SSH 密钥对

如果您还没有 SSH 密钥对，请首先生成一对密钥。在终端中执行以下命令：

ssh-keygen -t rsa -C "your.email@example.com" -b 4096

这将生成一个 RSA 类型的密钥对，并将私钥保存在 ~/.ssh/id_rsa，公钥保存在 ~/.ssh/id_rsa.pub。

复制公钥内容

打开公钥文件 ~/.ssh/id_rsa.pub，将其中的内容复制到剪贴板。您可以使用以下命令来完成：

macOS:

pbcopy < ~/.ssh/id_rsa.pub

GNU/Linux (requires the xclip package):

xclip -sel clip < ~/.ssh/id_rsa.pub

Windows Command Line:

type %userprofile%\.ssh\id_rsa.pub | clip

Git Bash on Windows / Windows PowerShell:

cat ~/.ssh/id_rsa.pub | clip

将您的SSH密钥添加到GitLab。

1. 登录到 GitLab

2. 打开您的 GitLab 帐户，在右上角点击个人头像，选择设置

3. 在左侧导航到 SSH 密钥设置

4. 在 "SSH Keys" 页面，粘贴之前复制的公钥内容到 "Key" 字段中，并为该密钥添加一个可识别的标题（如 "My SSH Key"）。然后点击 "Add Key" 按钮。

验证 SSH 密钥

GitLab 将验证并添加您提供的 SSH 密钥。如果一切顺利，您将在页面上看到成功的消息。

测试 SSH 连接

为了确保 SSH 密钥配置正确，您可以在终端中执行以下命令进行测试：

ssh -T git@gitlab.com

如果配置正确，您将看到与 GitLab 相关的欢迎消息。
现在，您已经成功在 GitLab 中配置了 SSH 密钥。这将允许您通过 SSH 协议进行与 GitLab 之间的安全通信，例如进行代码的克隆、推送和拉取操作。

ssh-add --apple-use-keychain ~/.ssh/id_rsa &> /dev/null

提示

如果想在代码 Push 后，或者 Merge request 后，自动部署，可以采用多种方案，以下介绍两种

不知道如何配置的同学，可以参考一下

1. 通过 Jenkins 提供的【触发远程构建】

1.1. 勾选【触发远程构建】并填入 token

1.2. 配置 API token

1. 打开 Jenkins 控制台。

2. 在顶部导航栏中，点击您的用户名，然后选择 "Configure" 选项。

3. 在配置页面中，向下滚动，找到 "API Token" 部分。

4. 如果您之前没有生成过 API Token，则点击 "Add new Token" 或 "Generate Token" 按钮。

5. 在生成或更改 Token 的过程中，您可能需要提供您的 Jenkins 用户密码进行身份验证。

6. 生成或更改成功后，您将看到新生成的 Token 值。请将其复制并妥善保存，因为在以后的访问中，您将无法再查看该 Token 的值。

1.3. 如何调用 Url

Jenkins 提供了便捷的远程触发功能，但是需要配置一个 token，然后在 push 后，通过 post 请求，调用 Jenkins 的 url 即可触发构建

调用 url 可以使用 python 脚本，或者 curl 命令，一般配合 git 提交，使用 curl 命令居多

下面以 GitLab CI/CD 为例进行举例

GitLab CI/CD 是一个简洁好用的的持续集成/持续交付的框架。通过为你的项目配置一个或者多个 GitLab Runner，然后撰写一个 .gitlab-ci.yml，你就可以很方便地利用 GitLab CI/CD 来为你的项目引入持续集成/交付的功能。比较类似之前介绍过的GitHubAction

GitLab CI/CD 是通过 GitLab Runner 来执行的

GitLab CI/CD 将按照 Stage 定义的顺序来执行，任何一个 Stage 失败，整个 CI/CD 将失败

每一个 Stage 可以被若干个 Job 关联。Stage 在执行的时候，关联到这个 Stage 的所有 Job 都将被执行，不过不同的 Job 可能是并行执行的。

每个 Job 在执行的时候，会先按照缓存策略加载缓存数据，然后按照顺序依次运行 before_script、script 和 after_script 中配置的脚本，运行完毕以后，会将生成的数据保存到缓存中。

1.4. 编写.gitlab-ci.yml

stages:
  - deploy

deploy_to_hyjk_open-x:
  stage: deploy
  only:
    - master
  script:
    - ./deploy.sh

大意是当 master 分支 deploy 时执行 ./deploy.sh 脚本
这里 script 调用了一个 shell 脚本，因为在 yml 文件中写脚本比较麻烦，个人比较习惯在 sh 文件中写脚本，然后在 yml 文件中调用这个脚本即可

1.5. deploy.sh

由于新版本的 Jenkins 安全机制，每次调用 API 前都需要先调用获取获取 CSRF crumb 值的接口

下面脚本演示了，如何先获取 crumb 的值，并在之后触发远程构建 API 的时候，携带这个值

#!/bin/bash

# Jenkins 服务器信息
JENKINS_URL="http://192.168.155.57:8080/"
JENKINS_USERNAME="admin"
JENKINS_API_TOKEN="11abf441f4db6e341ae65b660f74de6e02"

# 获取 CSRF crumb 值
CRUMB=$(curl -s -u "$JENKINS_USERNAME:$JENKINS_API_TOKEN" "$JENKINS_URL/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,\":\",//crumb)")

# 提取 crumb 值
CRUMB_VALUE=$(echo "$CRUMB" | awk -F':' '{print $2}')

# 执行 Jenkins 远程构建
curl -X POST "$JENKINS_URL/job/projectName/build?token=xZ7Y3n9A" \
  --user "$JENKINS_USERNAME:$JENKINS_API_TOKEN" \
  --header "Jenkins-Crumb: $CRUMB_VALUE"

2. 通过 GitLab 的 webhook 触发远程构建

使用 gitlab 的 webhook 配合 Jenkins 实现自动化部署。
Jenkins 需要安装 GitLab Plugin 插件，然后配置 webhook 即可。

2.1. 勾选插件选项

2.2. 选择配置

插件有很多配置项，这里我们常用的就是过滤分支，可以选择，有以下选项

• Include
• Exclude
• 正则表达式
• tag

2.3. 将生成的 url 和 token 填入 GitLab 中

可以选择触发的 events

2.4. 查看运行结果

1. 前言

有的同学可能会讲，CSS属性我倒是知道，例如：

p{
  color : red;
}

上面的 CSS 代码中，p 是元素选择器，color 就是其中的一个 CSS 属性。

但是要说 CSS 属性的计算过程，还真的不是很清楚。

没关系，通过此篇文章，能够让你彻底明白什么是 CSS 属性的计算流程。

首先，不知道你有没有考虑过这样的一个问题，假设在 HTML 中有这么一段代码：

<body>
  <h1>这是一个h1标题</h1>
</body>

上面的代码也非常简单，就是在 body 中有一个 h1 标题而已，该 h1 标题呈现出来的外观是如下：

目前我们没有设置该 h1 的任何样式，但是却能看到该 h1 有一定的默认样式，例如有默认的字体大小、默认的颜色。

那么问题来了，我们这个 h1 元素上面除了有默认字体大小、默认颜色等属性以外，究竟还有哪些属性呢？

答案是该元素上面会有 CSS 所有的属性。你可以打开浏览器的开发者面板，选择【元素】，切换到【计算样式】，之后勾选【全部显示】，此时你就能看到在此 h1 上面所有 CSS 属性对应的值。

换句话说，我们所书写的任何一个 HTML 元素，实际上都有完整的一整套 CSS 样式。这一点往往是让初学者比较意外的，因为我们平时在书写 CSS 样式时，往往只会书写必要的部分，例如前面的：

p{
  color : red;
}

这往往会给我们造成一种错觉，认为该 p 元素上面就只有 color 属性。而真实的情况确是，任何一个 HTML 元素，都有一套完整的 CSS 样式，只不过你没有书写的样式，大概率可能会使用其默认值。例如上图中 h1 一个样式都没有设置，全部都用的默认值。

但是注意，我这里强调的是“大概率可能”，难道还有我们“没有设置值，但是不使用默认值”的情况么？

嗯，确实有的，所以我才强调你要了解“CSS 属性的计算过程”。

总的来讲，属性值的计算过程，分为如下这么 4 个步骤：

• 确定声明值
• 层叠冲突
• 使用继承
• 使用默认值

确定声明值

首先第一步，是确定声明值。所谓声明值就是作者自己所书写的 CSS 样式，例如前面的：

p{
  color : red;
}

这里我们声明了 p 元素为红色，那么就会应用此属性设置。

当然，除了作者样式表，一般浏览器还会存在“用户代理样式表”，简单来讲就是浏览器内置了一套样式表。

在上面的示例中，作者样式表中设置了 color 属性，而用户代理样式表（浏览器提供的样式表）中设置了诸如 display、margin-block-start、margin-block-end、margin-inline-start、margin-inline-end 等属性对应的值。

这些值目前来讲也没有什么冲突，因此最终就会应用这些属性值。

层叠冲突

在确定声明值时，可能出现一种情况，那就是声明的样式规则发生了冲突。

此时会进入解决层叠冲突的流程。而这一步又可以细分为下面这三个步骤：

• 比较源的重要性
• 比较优先级
• 比较次序

来来来，我们一步一步来看。

比较源的重要性

当不同的 CSS 样式来源拥有相同的声明时，此时就会根据样式表来源的重要性来确定应用哪一条样式规则。

那么问题来了，咱们的样式表的源究竟有几种呢？

整体来讲有三种来源：

• 浏览器会有一个基本的样式表来给任何网页设置默认样式。这些样式统称用户代理样式。
• 网页的作者可以定义文档的样式，这是最常见的样式表，称之为页面作者样式。
• 浏览器的用户，可以使用自定义样式表定制使用体验，称之为用户样式。

对应的重要性顺序依次为：页面作者样式 > 用户样式 > 用户代理样式

更详细的来源重要性比较，可以参阅 MDN：https://developer.mozilla.org/zh-CN/docs/Web/CSS/Cascade

我们来看一个示例。

例如现在有页面作者样式表和用户代理样式表中存在属性的冲突，那么会以作者样式表优先。

p{
  color : red;
  display: inline-block;
}

可以明显的看到，作者样式表和用户代理样式表中同时存在的 display 属性的设置，最终作者样式表干掉了用户代理样式表中冲突的属性。这就是第一步，根据不同源的重要性来决定应用哪一个源的样式。

比较优先级

那么接下来，如果是在在同一个源中有样式声明冲突怎么办呢？此时就会进行样式声明的优先级比较。

例如：

<div class="test">
  <h1>test</h1>
</div>

.test h1{
  font-size: 50px;
}

h1 {
  font-size: 20px;
}

在上面的代码中，同属于页面作者样式，源的重要性是相同的，此时会以选择器的权重来比较重要性。

很明显，上面的选择器的权重要大于下面的选择器，因此最终标题呈现为 50px。

可以看到，落败的作者样式在 Elements>Styles 中会被划掉。

有关选择器权重的计算方式，不清楚的同学，可以进入此传送门：https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity

比较次序

经历了上面两个步骤，大多数的样式声明能够被确定下来。但是还剩下最后一种情况，那就是样式声明既是同源，权重也相同。

此时就会进入第三个步骤，比较样式声明的次序。

举个例子：

h1 {
  font-size: 50px;
}

h1 {
  font-size: 20px;
}

在上面的代码中，同样都是页面作者样式，选择器的权重也相同，此时位于下面的样式声明会层叠掉上面的那一条样式声明，最终会应用 20px 这一条属性值。

至此，样式声明中存在冲突的所有情况，就全部被解决了。

使用继承

层叠冲突这一步完成后，解决了相同元素被声明了多条样式规则究竟应用哪一条样式规则的问题。

那么如果没有声明的属性呢？此时就使用默认值么？

No、No、No，别急，此时还有第三个步骤，那就是使用继承而来的值。

例如：

<div>
  <p>Lorem ipsum dolor sit amet.</p>
</div>

div {
  color: red;
}

在上面的代码中，我们针对 div 设置了 color 属性值为红色，而针对 p 元素我们没有声明任何的属性，但是由于 color 是可以继承的，因此 p 元素从最近的 div 身上继承到了 color 属性的值。

这里有两个点需要同学们注意一下。

首先第一个是我强调了是最近的 div 元素，看下面的例子：

<div class="test">
  <div>
    <p>Lorem ipsum dolor sit amet.</p>
  </div>
</div>

div {
  color: red;
}
.test{
  color: blue;
}

因为这里并不涉及到选中 p 元素声明 color 值，而是从父元素上面继承到 color 对应的值，因此这里是谁近就听谁的，初学者往往会产生混淆，又去比较权重，但是这里根本不会涉及到权重比较，因为压根儿就没有选中到 p 元素。

第二个就是哪些属性能够继承？

关于这一点的话，大家可以在 MDN 上面很轻松的查阅到。例如我们以 text-align 为例，如下图所示：

使用默认值

好了，目前走到这一步，如果属性值都还不能确定下来，那么就只能是使用默认值了。

如下图所示：

前面我们也说过，一个 HTML 元素要在浏览器中渲染出来，必须具备所有的 CSS 属性值，但是绝大部分我们是不会去设置的，用户代理样式表里面也不会去设置，也无法从继承拿到，因此最终都是用默认值。

好了，这就是关于 CSS 属性计算过程的所有知识了。

一道面试题

好了，学习了今天的内容，让我来用一道面试题测试测试大家的理解程度。

下面的代码，最终渲染出来的效果，a 元素是什么颜色？p 元素又是什么颜色？

<div>
  <a href="">test</a>
  <p>test</p>
</div>

div {
  color: red;
}

大家能说出为什么会呈现这样的结果么？

解答如下：

实际上原因很简单，因为 a 元素在用户代理样式表中已经设置了 color 属性对应的值，因此会应用此声明值。而在 p 元素中无论是作者样式表还是用户代理样式表，都没有对此属性进行声明，然而由于 color 属性是可以继承的，因此最终 p 元素的 color 属性值通过继承来自于父元素。

你答对了么？-）

但是一说到 CSS 包含块，有的小伙伴就懵圈了，什么是包含块？好像从来没有听说过这玩意儿。

好吧，如果你对包含块的知识一无所知，那么系好安全带，咱们准备出发了。

包含块英语全称为containing block，实际上平时你在书写 CSS 时，大多数情况下你是感受不到它的存在，因此你不知道这个知识点也是一件很正常的事情。但是这玩意儿是确确实实存在的，在 CSS 规范中也是明确书写了的：

https://drafts.csswg.org/css2/#containing-block-details

并且，如果你不了解它的运作机制，有时就会出现一些你认为的莫名其妙的现象。

那么，这个包含块究竟说了什么内容呢？

说起来也简单，就是元素的尺寸和位置，会受它的包含块所影响。对于一些属性，例如 width, height, padding, margin，绝对定位元素的偏移值（比如 position 被设置为 absolute 或 fixed），当我们对其赋予百分比值时，这些值的计算值，就是通过元素的包含块计算得来。

来吧，少年，让我们从最简单的 case 开始看。

<body>
  <div class="container">
    <div class="item"></div>
  </div>
</body>

.container{
  width: 500px;
  height: 300px;
  background-color: skyblue;
}
.item{
  width: 50%;
  height: 50%;
  background-color: red;
}

请仔细阅读上面的代码，然后你认为 div.item 这个盒子的宽高是多少？

相信你能够很自信的回答这个简单的问题，div.item 盒子的 width 为 250px，height 为 150px。

这个答案确实是没有问题的，但是如果我追问你是怎么得到这个答案的，我猜不了解包含块的你大概率会说，因为它的父元素 div.container 的 width 为 500px，50% 就是 250px，height 为 300px，因此 50% 就是 150px。

这个答案实际上是不准确的。正确的答案应该是，div.item 的宽高是根据它的包含块来计算的，而这里包含块的大小，正是这个元素最近的祖先块元素的内容区。

因此正如我前面所说，很多时候你都感受不到包含块的存在。

包含块分为两种，一种是根元素（HTML 元素）所在的包含块，被称之为初始包含块（initial containing block）。对于浏览器而言，初始包含块的的大小等于视口 viewport 的大小，基点在画布的原点（视口左上角）。它是作为元素绝对定位和固定定位的参照物。

另外一种是对于非根元素，对于非根元素的包含块判定就有几种不同的情况了。大致可以分为如下几种：

• 如果元素的 positiion 是 relative 或 static ，那么包含块由离它最近的块容器（block container）的内容区域（content area）的边缘建立。
• 如果 position 属性是 fixed，那么包含块由视口建立。
• 如果元素使用了 absolute 定位，则包含块由它的最近的 position 的值不是 static （也就是值为fixed、absolute、relative 或 sticky）的祖先元素的内边距区的边缘组成。

前面两条实际上都还比较好理解，第三条往往是初学者容易比较忽视的，我们来看一个示例：

<body>
    <div class="container">
      <div class="item">
        <div class="item2"></div>
      </div>
    </div>
  </body>

.container {
  width: 500px;
  height: 300px;
  background-color: skyblue;
  position: relative;
}
.item {
  width: 300px;
  height: 150px;
  border: 5px solid;
  margin-left: 100px;
}
.item2 {
  width: 100px;
  height: 100px;
  background-color: red;
  position: absolute;
  left: 10px;
  top: 10px;
}

首先阅读上面的代码，然后你能在脑海里面想出其大致的样子么？或者用笔和纸画一下也行。

公布正确答案：

怎么样？有没有和你所想象的对上？

其实原因也非常简单，根据上面的第三条规则，对于 div.item2 来讲，它的包含块应该是 div.container，而非 div.item。

如果你能把上面非根元素的包含块判定规则掌握，那么关于包含块的知识你就已经掌握 80% 了。

实际上对于非根元素来讲，包含块还有一种可能，那就是如果 position 属性是 absolute 或 fixed，包含块也可能是由满足以下条件的最近父级元素的内边距区的边缘组成的：

• transform 或 perspective 的值不是 none
• will-change 的值是 transform 或 perspective
• filter 的值不是 none 或 will-change 的值是 filter(只在 Firefox 下生效).
• contain 的值是 paint (例如: contain: paint;)

我们还是来看一个示例：

<body>
  <div class="container">
    <div class="item">
      <div class="item2"></div>
    </div>
  </div>
</body>

.container {
  width: 500px;
  height: 300px;
  background-color: skyblue;
  position: relative;
}
.item {
  width: 300px;
  height: 150px;
  border: 5px solid;
  margin-left: 100px;
  transform: rotate(0deg); /* 新增代码 */
}
.item2 {
  width: 100px;
  height: 100px;
  background-color: red;
  position: absolute;
  left: 10px;
  top: 10px;
}

我们对于上面的代码只新增了一条声明，那就是 transform: rotate(0deg)，此时的渲染效果却发生了改变，如下图所示：

可以看到，此时对于 div.item2 来讲，包含块就变成了 div.item。

好了，到这里，关于包含块的知识就基本讲完了。

我们再把 CSS 规范中所举的例子来看一下。

<html>
  <head>
    <title>Illustration of containing blocks</title>
  </head>
  <body id="body">
    <div id="div1">
      <p id="p1">This is text in the first paragraph...</p>
      <p id="p2">
        This is text
        <em id="em1">
          in the
          <strong id="strong1">second</strong>
          paragraph.
        </em>
      </p>
    </div>
  </body>
</html>

上面是一段简单的 HTML 代码，在没有添加任何 CSS 代码的情况下，你能说出各自的包含块么？

对应的结果如下：

| 元素 | 包含块 |
|

Here comes Module!

随着网站逐渐变成「互联网应用程序」，嵌入网页的 JavaScript 代码越来越庞大，越来越复杂。网页越来越像桌面程序，需要一个团队分工协作、进度管理、单元测试……我们不得不使用软件工程的方法，来管理网页的业务逻辑。

于是，JavaScript 的模块化成为迫切需求。在 ES6 Module 来临之前，JavaScript 社区提供了强大支持，尝试在现有的运行环境下，实现模块的效果。

1995 年，它作为网景浏览器（Netscape Navigator）的一部分首次发布，网景给这个新语言命名为 LiveScript。一年后，为了搭上当时媒体热炒 Java 的顺风车，临时改名为了 JavaScript （当然，Java 和 JavaScript 的关系，就和雷锋和雷锋塔一样 —— 并没有什么关系）

歪果仁的笑话怎么一点都不好笑

译者注：wikipedia 的 JavaScript 词条 更详细的叙述了这段历史

1996 年，网景将 JavaScript 提交给 ECMA International（欧洲计算机制造商协会） 进行标准化，并最终确定出新的语言标准，它就是 ECMAScript。自此，ECMAScript 成为所有 JavaScript 实现的基础，不过，由于 JavaScript 名字的历史原因和市场原因（很显然 ECMAScript 这个名字并不令人喜欢……），现实中我们只用 ECMAScript 称呼标准，平时都还是使用 JavaScript 来称呼这个语言。

术语（译者注）：

• 标准（Standard）： 用于定义与其他事物区别的一套规则
• 实现（Implementation）： 某个标准的具体实施/真实实践

不过，JavaScript 开发者们并不怎么在乎这些，因为在诞生之后的 15 年里，ECMAScript 并没有多少变化，而且现实中的很多实现都已经和标准大相径庭。其实在第一版的 ECMAScript 发布后，很快又跟进发布了两个版本，但是自从 1999 年 ECMAScript 3 发布后，十年内都没有任何改动被成功添加到官方规范里。取而代之的，是各大浏览器厂商们争先进行自己的语言拓展，web 开发者们别无选择只能去尝试并且支持这些 API。即使是在 2009 年 ECMAScript 5 发布之后，仍然用了数年这些新规范才得到了浏览器的广泛支持，可是大部分开发者还是写着 ECMAScript 3 风格的代码，并不觉得有必要去了解这些规范。

译者注：ECMAScript 第四版草案由于太过激进而被抛弃，Adobe 的 ActionScript 3.0 是 ECMAScript edition 4 的唯一实现（ Flash 差点就统一 Web 了）

到了 2012 年，事情突然开始有了转变。大家开始推动停止对旧版本 IE 浏览器的支持，用 ECMAScript 5 (ES5) 风格来编写代码也变得更加可行。与此同时，一个新的 ECMAScript 规范也开始启动。到了这时，大家开始逐渐习惯以对 ECMAScript 规范的版本支持程度来形容各种 JavaScript 实现。在正式被指名为 ECMAScript 第 6 版 (ES6) 之前，这个新的标准原本被称为 ES.Harmony（和谐）。2015 年，负责制定 ECMAScript 规范草案的委员会 TC39 决定将定义新标准的制度改为一年一次，这意味着每个新特性一旦被批准就可以添加，而不像以往一样，规范只有在整个草案完成，所有特性都没问题后才能被定稿。因此，ECMAScript 第 6 版在六月份公布之前，又被重命名为了 ECMAScript 2015（ES2015）

目前，仍然有很多新的 JavaScript 特性或语法正在提议中，包括 decorators（装饰者），async-await（async-await 异步编程模型） 和 static class properties（静态类属性）。它们通常被称为 ES7，ES2016 或者 ES.Next 的特性，不过实际上它们只能被称作提案或者说可能性，毕竟 ES2016 的规范还没有完成，有可能全部都会引入，也有可能一个都没有。TC39 把一个提案分为 4 个阶段，你可以在 Babel 的官网 上查看各个提案目前都在哪个阶段了。

所以，我们该如何使用这一大堆术语呢？下面的列表或许能帮助到你：

• ECMAScript：一个由 ECMA International 进行标准化，TC39 委员会进行监督的语言。通常用于指代标准本身。
• JavaScript：ECMAScript 标准的各种实现的最常用称呼。这个术语并不局限于某个特定版本的 ECMAScript 规范，并且可能被用于任何不同程度的任意版本的 ECMAScript 的实现。
• ECMAScript 5 (ES5)：ECMAScript 的第五版修订，于 2009 年完成标准化。这个规范在所有现代浏览器中都相当完全的实现了。
• ECMAScript 6 (ES6) / ECMAScript 2015 (ES2015)：ECMAScript 的第六版修订，于 2015 年完成标准化。这个标准被部分实现于大部分现代浏览器。可以查阅这张兼容性表来查看不同浏览器和工具的实现情况。
• ECMAScript 2016：预计的第七版 ECMAScript 修订，计划于明年夏季发布。这份规范具体将包含哪些特性还没有最终确定
• ECMAScript Proposals：被考虑加入未来版本 ECMAScript 标准的特性与语法提案，他们需要经历五个阶段：Strawman（稻草人），Proposal（提议），Draft（草案），Candidate（候选）以及 Finished （完成）。

在这整个 Blog 中，我将把目前的 ECMAScript 版本称作 ES6（因为这是大部分开发者最习以为常的），把明年的规范称作 ES2016（因为，与 ES6/ES2015 不同，这个名字将在整个标准化过程中沿用）并且将那些还没有成为 ECMAScript 定稿或草案的未来语言概念称为 ECMAScript 提案或者 JavaScript 提案。我将尽我所能在任何可能引起困惑的场合沿用这篇文章。

一些资源

• TC39 的 Github 仓库上可以看到所有目前公开的提案
• 如果你还不熟悉 ES6，Babel 有一个很不错的特性概览
• 如果你希望深入 ES6，这里有两本很不错的书： Axel Rauschmayer 的 Exploring ES6和 Nicholas Zakas 的 Understanding ECMAScript 6。Axel 的博客 2ality 也是很不错的 ES6 资源

来学 JavaScript 吧！

著作权声明

本文译自 ES5, ES6, ES2016, ES.Next: What's going on with JavaScript versioning?
译者 黄玄，首次发布于 Hux Blog，转载请保留以上链接

通过 js 判断 moblie 端和 pc 端进而加载不同的 css 或者 js

废话不多说，上代码

<script type="text/javascript">
function browserRedirect() {
var sUserAgent = navigator.userAgent.toLowerCase();
var bIsIpad = sUserAgent.match(/ipad/i) == "ipad";
var bIsIphoneOs = sUserAgent.match(/iphone os/i) == "iphone os";
var bIsMidp = sUserAgent.match(/midp/i) == "midp";
var bIsUc7 = sUserAgent.match(/rv:1.2.3.4/i) == "rv:1.2.3.4";
var bIsUc = sUserAgent.match(/ucweb/i) == "ucweb";
var bIsAndroid = sUserAgent.match(/android/i) == "android";
var bIsCE = sUserAgent.match(/windows ce/i) == "windows ce";
var bIsWM = sUserAgent.match(/windows mobile/i) == "windows mobile";
// document.writeln("您的浏览设备为：");
if (bIsIpad || bIsIphoneOs || bIsMidp || bIsUc7 || bIsUc || bIsAndroid || bIsCE || bIsWM) {

// alert("手机浏览！");


} else {

// alert("PC浏览！");
document.write("<script type='text/javascript' size='150' alpha='0.8' zIndex='-10' src='../js/dist/ribbon.js'><\/script>");
document.write("<script type='text/javascript' color='0,188,212' opacity='0.7' zIndex='-2' count='99' src='http://cdn.bootcss.com/canvas-nest.js/1.0.1/canvas-nest.min.js'><\/script>");
	}
}
browserRedirect();
</script>

需要注意的是字符转义和引号嵌套的问题

何为进程？

程序运行需要有它自己专属的内存空间，可以把这块内存空间简单的理解为进程

每个应用至少有一个进程，进程之间相互独立，即使要通信，也需要双方同意。

何为线程？

有了进程后，就可以运行程序的代码了。

运行代码的「人」称之为「线程」。

一个进程至少有一个线程，所以在进程开启后会自动创建一个线程来运行代码，该线程称之为主线程。

如果程序需要同时执行多块代码，主线程就会启动更多的线程来执行代码，所以一个进程中可以包含多个线程。

浏览器有哪些进程和线程？

浏览器是一个多进程多线程的应用程序

浏览器内部工作极其复杂。

为了避免相互影响，为了减少连环崩溃的几率，当启动浏览器后，它会自动启动多个进程。

可以在浏览器的任务管理器中查看当前的所有进程

其中，最主要的进程有：

1. 浏览器进程

   主要负责界面显示、用户交互、子进程管理等。浏览器进程内部会启动多个线程处理不同的任务。

2. 网络进程

   负责加载网络资源。网络进程内部会启动多个线程来处理不同的网络任务。

3. 渲染进程（本节课重点讲解的进程）

   渲染进程启动后，会开启一个渲染主线程，主线程负责执行 HTML、CSS、JS 代码。

   默认情况下，浏览器会为每个标签页开启一个新的渲染进程，以保证不同的标签页之间不相互影响。

   将来该默认模式可能会有所改变，有兴趣的同学可参见chrome官方说明文档

渲染主线程是如何工作的？

渲染主线程是浏览器中最繁忙的线程，需要它处理的任务包括但不限于：

• 解析 HTML
• 解析 CSS
• 计算样式
• 布局
• 处理图层
• 每秒把页面画 60 次
• 执行全局 JS 代码
• 执行事件处理函数
• 执行计时器的回调函数
• ......

思考题：为什么渲染进程不适用多个线程来处理这些事情？

要处理这么多的任务，主线程遇到了一个前所未有的难题：如何调度任务？

比如：

• 我正在执行一个 JS 函数，执行到一半的时候用户点击了按钮，我该立即去执行点击事件的处理函数吗？
• 我正在执行一个 JS 函数，执行到一半的时候某个计时器到达了时间，我该立即去执行它的回调吗？
• 浏览器进程通知我“用户点击了按钮”，与此同时，某个计时器也到达了时间，我应该处理哪一个呢？
• ......

渲染主线程想出了一个绝妙的主意来处理这个问题：排队

1. 在最开始的时候，渲染主线程会进入一个无限循环
2. 每一次循环会检查消息队列中是否有任务存在。如果有，就取出第一个任务执行，执行完一个后进入下一次循环；如果没有，则进入休眠状态。
3. 其他所有线程（包括其他进程的线程）可以随时向消息队列添加任务。新任务会加到消息队列的末尾。在添加新任务时，如果主线程是休眠状态，则会将其唤醒以继续循环拿取任务

这样一来，就可以让每个任务有条不紊的、持续的进行下去了。

整个过程，被称之为事件循环（消息循环）

若干解释

何为异步？

代码在执行过程中，会遇到一些无法立即处理的任务，比如：

• 计时完成后需要执行的任务 —— setTimeout、setInterval
• 网络通信完成后需要执行的任务 -- XHR、Fetch
• 用户操作后需要执行的任务 -- addEventListener

如果让渲染主线程等待这些任务的时机达到，就会导致主线程长期处于「阻塞」的状态，从而导致浏览器「卡死」

渲染主线程承担着极其重要的工作，无论如何都不能阻塞！

因此，浏览器选择异步来解决这个问题

使用异步的方式，渲染主线程永不阻塞

面试题：如何理解 JS 的异步？

参考答案：

JS是一门单线程的语言，这是因为它运行在浏览器的渲染主线程中，而渲染主线程只有一个。

而渲染主线程承担着诸多的工作，渲染页面、执行 JS 都在其中运行。

如果使用同步的方式，就极有可能导致主线程产生阻塞，从而导致消息队列中的很多其他任务无法得到执行。这样一来，一方面会导致繁忙的主线程白白的消耗时间，另一方面导致页面无法及时更新，给用户造成卡死现象。

所以浏览器采用异步的方式来避免。具体做法是当某些任务发生时，比如计时器、网络、事件监听，主线程将任务交给其他线程去处理，自身立即结束任务的执行，转而执行后续代码。当其他线程完成时，将事先传递的回调函数包装成任务，加入到消息队列的末尾排队，等待主线程调度执行。

在这种异步模式下，浏览器永不阻塞，从而最大限度的保证了单线程的流畅运行。

JS为何会阻碍渲染？

先看代码

<h1>Mr.Yuan is awesome!</h1>
<button>change</button>
<script>
  var h1 = document.querySelector('h1');
  var btn = document.querySelector('button');

  // 死循环指定的时间
  function delay(duration) {
    var start = Date.now();
    while (Date.now() - start < duration) {}
  }

  btn.onclick = function () {
    h1.textContent = '袁老师很帅！';
    delay(3000);
  };
</script>

点击按钮后，会发生什么呢？

任务有优先级吗？

任务没有优先级，在消息队列中先进先出

但消息队列是有优先级的

根据 W3C 的最新解释:

• 每个任务都有一个任务类型，同一个类型的任务必须在一个队列，不同类型的任务可以分属于不同的队列。
  在一次事件循环中，浏览器可以根据实际情况从不同的队列中取出任务执行。
• 浏览器必须准备好一个微队列，微队列中的任务优先所有其他任务执行
  https://html.spec.whatwg.org/multipage/webappapis.html#perform-a-microtask-checkpoint

随着浏览器的复杂度急剧提升，W3C 不再使用宏队列的说法

在目前 chrome 的实现中，至少包含了下面的队列：

• 延时队列：用于存放计时器到达后的回调任务，优先级「中」
• 交互队列：用于存放用户操作后产生的事件处理任务，优先级「高」
• 微队列：用户存放需要最快执行的任务，优先级「最高」

// 立即把一个函数添加到微队列
Promise.resolve().then(函数)

浏览器还有很多其他的队列，由于和我们开发关系不大，不作考虑

面试题：阐述一下 JS 的事件循环

参考答案：

事件循环又叫做消息循环，是浏览器渲染主线程的工作方式。

在 Chrome 的源码中，它开启一个不会结束的 for 循环，每次循环从消息队列中取出第一个任务执行，而其他线程只需要在合适的时候将任务加入到队列末尾即可。

过去把消息队列简单分为宏队列和微队列，这种说法目前已无法满足复杂的浏览器环境，取而代之的是一种更加灵活多变的处理方式。

根据 W3C 官方的解释，每个任务有不同的类型，同类型的任务必须在同一个队列，不同的任务可以属于不同的队列。不同任务队列有不同的优先级，在一次事件循环中，由浏览器自行决定取哪一个队列的任务。但浏览器必须有一个微队列，微队列的任务一定具有最高的优先级，必须优先调度执行。

面试题：JS 中的计时器能做到精确计时吗？为什么？

参考答案：

不行，因为：

1. 计算机硬件没有原子钟，无法做到精确计时
2. 操作系统的计时函数本身就有少量偏差，由于 JS 的计时器最终调用的是操作系统的函数，也就携带了这些偏差
3. 按照 W3C 的标准，浏览器实现计时器时，如果嵌套层级超过 5 层，则会带有 4 毫秒的最少时间，这样在计时时间少于 4 毫秒时又带来了偏差
4. 受事件循环的影响，计时器的回调函数只能在主线程空闲时运行，因此又带来了偏差

相关信息

永远不要过早优化，优化也有相应的代价

• 开发时间变长
• 开发成本增加
• 代码难以阅读
• 增加维护成本

何时优化，因地制宜，是一门艺术，尽量把优化的思想带入写代码的过程中

本文章的优化手段基于vue2

服务端渲染 SSR or 预渲染

客户端渲染：使用 JavaScript 框架进行页面渲染
服务端渲染：服务端将HTML文本组装好，并返回给浏览器，这个HTML文本被浏览器解析之后，不需要经过 JavaScript 脚本的执行，即可直接构建出希望的 DOM 树并展示到页面中，最后将这些静态标记"激活"为客户端上完全可交互的应用程序。

优点：

更好的 SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。对客户端渲染的页面来说，简直无能为力，因为返回的HTML是一个空壳，它需要执行 JavaScript 脚本之后才会渲染真正的页面。
用户将会更快速地看到完整渲染的页面

缺点:

为了实现服务端渲染，应用代码中需要兼容服务端和客户端两种运行情况
由于服务器增加了渲染HTML的需求，使得原本只需要输出静态资源文件的nodejs服务，新增了数据获取的IO和渲染HTML的CPU占用，
服务器渲染应用程序，需要处于 Node.js server 运行环境。

如何实现？

想要在服务器端渲染，我们需要做什么呢？那就是同构我们的项目，Vue.js 是构建客户端应用程序的框架，服务器渲染的 Vue.js 应用程序也可以被认为是"同构"或"通用"，因为应用程序的大部分代码都可以在服务器和客户端上运行

当运行在不同环境中时，我们的代码将不会完全相同，同构就是让一份代码，既可以在服务端中执行，也可以在客户端中执行，并且执行的效果都是一样的，都是完成这个html的组装，正确的显示页面。
对于同构应用来说，我们必须实现客户端与服务端的路由、模型组件、数据模型的共享。

服务器端渲染注意事项

为避免造成交叉请求状态污染，每个请求应该都是全新的、独立的应用程序实例。
由于没有动态更新，所有的生命周期钩子函数中，只有 beforeCreate 和 created 会在服务器端渲染(SSR)过程中被调用。
通用代码不可接受像 window 或 document，这种仅浏览器可用的全局变量
浏览器可能会更改的一些特殊的 HTML 结构，例如，浏览器会在

内部自动注入 ，然而，由于 Vue 生成的虚拟 DOM(virtual DOM) 不包含 ，所以会导致无法匹配。

使用key

对于通过循环生成的列表，应给每个列表项一个稳定且唯一的key，这有利于在列表变动时，尽量少的删除、新增、改动元素

使用冻结的对象

冻结的对象不会被响应化，如果对象很多，嵌套结构很深，遍历过程需要花费很多时间，如果对象不需要动态更改，可以使用冻结对象，如：商品列表等纯展示页面，并不会通过用户交互来更改

var obj = {a:1,b:2}
// 冻结对象
Object.freeze(obj)
// 尝试更改
obj.a = 3
console.log(obj)
// 打印
{a:1,b:2}
// 验证
Object.isFrozen(obj)
// 结果
<.true

vue在处理过程中，如果发现对象是冻结对象，就不会去遍历对象，不会变成响应式

下面是1000000个对象的加载过程

vue

冻结对象

可见vue把对象深度遍历成为响应式，对于大量结构复杂的数据来说，是很耗时间的

使用函数式组件

函数式组件，设置functional:true，函数式组件没有data，这以为它无状态（没有响应式数据）

，也没用实例（没有this上下文），所以组件树中不存在函数式组件，一个函数式组件就像这样

Vue.component('my-component', {
  functional: true,
  // Props 是可选的
  props: {
    // ...
  },
  // 为了弥补缺少的实例
  // 提供第二个参数作为上下文
  render: function (createElement, context) {
    // ...
  }
})

注意：在 2.3.0 之前的版本中，如果一个函数式组件想要接收 prop，则 props 选项是必须的。在 2.3.0 或以上的版本中，你可以省略 props 选项，所有组件上的 attribute 都会被自动隐式解析为 prop。

当使用函数式组件时，该引用将会是 HTMLElement，因为他们是无状态的也是无实例的。

在 2.5.0 及以上版本中，如果你使用了单文件组件，那么基于模板的函数式组件可以这样声明：

<template functional>
</template>

组件需要的一切都是通过 context 参数传递，它是一个包括如下字段的对象：

• props：提供所有 prop 的对象
• children：VNode 子节点的数组
• slots：一个函数，返回了包含所有插槽的对象
• scopedSlots：(2.6.0+) 一个暴露传入的作用域插槽的对象。也以函数形式暴露普通插槽。
• data：传递给组件的整个数据对象，作为 createElement 的第二个参数传入组件
• parent：对父组件的引用
• listeners：(2.3.0+) 一个包含了所有父组件为当前组件注册的事件监听器的对象。这是 data.on 的一个别名。
• injections：(2.3.0+) 如果使用了 inject 选项，则该对象包含了应当被注入的 property。

在添加 functional: true 之后，需要更新我们的锚点标题组件的渲染函数，为其增加 context 参数，并将 this.$slots.default 更新为 context.children，然后将 this.level 更新为 context.props.level。

因为函数式组件只是函数，所以渲染开销(时间和内存)也低很多。

在作为包装组件时它们也同样非常有用。比如，当你需要做这些时：

• 程序化地在多个组件中选择一个来代为渲染；
• 在将 children、props、data 传递给子组件之前操作它们。

下面是一个 smart-list 组件的例子，它能根据传入 prop 的值来代为渲染更具体的组件：

var EmptyList = { /* ... */ }
var TableList = { /* ... */ }
var OrderedList = { /* ... */ }
var UnorderedList = { /* ... */ }

Vue.component('smart-list', {
  functional: true,
  props: {
    items: {
      type: Array,
      required: true
    },
    isOrdered: Boolean
  },
  render: function (createElement, context) {
    function appropriateListComponent () {
      var items = context.props.items

      if (items.length === 0)           return EmptyList
      if (typeof items[0] === 'object') return TableList
      if (context.props.isOrdered)      return OrderedList

      return UnorderedList
    }

    return createElement(
      appropriateListComponent(),
      context.data,
      context.children
    )
  }
})

使用计算属性

如果模版中某个数据会使用多次，并且该数据是通过计算得到的，使用计算属性以缓存它们

非实时绑定的表单项

当使用v-model绑定一个表单项时，当用户改变表单项的状态时，也会随之改变数据，从而导致vue发生重新渲染（rerender），这会带来一些性能的开销。

我们可以通过使用lazy或不使用v-model的方式解决该问题，但要注意，这样可能会导致在某一个时间段内数据和表单项的值是不一致的。

vue设计思想是关注的是数据而不是界面，代码的可维护性和可阅读性也很重要，js执行线程和浏览器渲染线程是互斥的，所以运行动画时执行jS线程动画会卡顿

如双向绑定的文本框输入的内容改变，输入abcd，会进行4次重新渲染，可以使用v-model.lazy,监听@change，不使用监听的是@input

保持对象引用稳定

在绝大部分情况下，vue出发rerender的时机是其依赖的数据发生变化

若数据没有发生变化，哪怕给数据重新赋值了，vue也不会做出任何处理的

下面是vue判断数据没有变化的源码

function hasChanged(x,y) {
  if (x === y) {
    return x === 0 && 1 / x !== 1/y
  }else {
    return x === x || y === y
  }
}

因此，如果需要，只要能保证组件的依赖数据不发生变化，组件就不会重新渲染

对于原始数据类型，保持其值不变即可

对于对象类型，保持其引用不变即可

使用v-show替代v-if

对于频繁切换显示状态的元素，使用v-show可以保证虚拟的dom树的稳定，避免频繁的新增和删除元素，特别是对于那些内部包含大量dom元素的节点，这一点及其重要

使用延迟装载defer

首页白屏时间主要受到两个因素的影响：

• 打包体积过大

  巨型包需要消耗大量的传输时间，导致JS传输完成前页面只有一个<div>，没有可显示的内容

• 需要立即渲染的内容太多

JS传输完成后，浏览器开始执行JS构造页面

但可能一开始要渲染的组件太多，不仅JS的事件很长，而且执行完后浏览器要渲染的元素过多，从而导致页面白屏loading过久

一个可行的办法就是延迟装载组件，让组件按照指定的先后顺序依次一个一个渲染出来

告诉浏览器——你希望执行一个动画，并且要求浏览器在下次重绘之前调用指定的回调函数更新动画。该方法需要传入一个回调函数作为参数，该回调函数会在浏览器下一次重绘之前执行

callback： 下一次重绘之前更新动画帧所调用的函数(即上面所说的回调函数)。该回调函数会被传入DOMHighResTimeStamp参数，该参数与performance.now()的返回值相同，它表示requestAnimationFrame() 开始去执行回调函数的时刻。

思路：浏览器渲染1s渲染60次，第一次渲染一部分，第二次一部分，隔开渲染,分批绘制

// defer.js
export default function(maxFrameCount) {
  return {
    data(){
      return{
        // 浏览器每重绘一次，计数
        frameCount:0,
      };
    },
    mounted() {
      const refreshFrameCount = () => {
        requestAnimationFrame(() => {
        	this.frameCount++;
          if(this.frameCount < maxFrameCount) {
            refreshFrameCount();
          }
        });
      };
      refreshFrameCount();
    },
    methods: {
      defer(showInFrameCount) {
        // 用于v-if 的判断条件，渲染次数大于showInFrameCount后继续下一次渲染
        return this.frameCount >= showInFrameCount
      },
    },
  };
}

<template>
  <div class="container">
    <!--vue3.0 v-if 优先级高 vue2.x v-for优先级高-->
    <div class="block" v-for="n in 20" v-if="defer(n)">
      <heavy-comp></heavy-comp>
    </div>
  </div>
</template>
<script>
import defer from "./mixin/defer";
export default {
  mixins: [defer(300)],
  components: { HeavyComp },
};
</script>

使用keep-alive

用于缓存内部组件实例，里面有include和exclude属性，max设置最大缓存数，超过后，自动删除最久没用的。

受到keep-alive影响，其内部的组件都具有两个生命周期，activated和deactivated ,分别再组件激活和失活时触发，第一次activated是在mounted之后。

一般用在需要多个页面频繁操作的场景（导航条）

长列表优化

一般用在app端下拉的时候，或者列表很长的时候，通过一个固定大小的渲染池来解决。通过滚动条等一些操作，减少页面渲染市场，有现成的库，vue-virtual-scroller

https://github.com/Akryum/vue-virtual-scroller

通过v-once创建低开销的静态组件，渲染一次后就缓存起来了，除非你非常留意渲染速度，不然最好不要用，因为有的开发者不知道这个属性或者看漏了，然后花费好几个小时来找为什么模板无法正确更新。

打包体积优化

• Webpack 对图片进行压缩
• 静态资源的优化使用对象存储加CDN
• 减少 ES6 转为 ES5 的冗余代码
• 提取公共代码
• 模板预编译
• 提取组件的 CSS
• 优化 SourceMap
• 构建结果输出分析
• Vue 项目的编译优化

基础优化

• 开启 gzip 压缩
• 浏览器缓存
• CDN 的使用
• 使用 Chrome Performance 查找性能瓶颈

前言

首先要知道vue2 是2013年 基于 ES5开发出来的，我们常说的重渲染就是重新运行render函数

vue2 的响应式原理是利⽤ES5 的⼀个 API ，Object.defineProperty()对数据进⾏劫持结合发布订阅模式的⽅式来实现的。

1. 思路

带入作者的角度思考一下，想要达成响应式的特点应该是:属性更新，自动调用依赖^[1]的函数进行重新渲染

1. 使用属性描述符Object.defineProperty监听属性的赋值
2. 赋值完成后调用依赖该属性的函数，那如何获取依赖的函数呢？看第三点
3. 由于依赖会调用属性的get方法，所以可以在get方法中收集依赖
4. 然后在set方法中执行这些依赖的函数，称为派发更新

基于以上思路的简单实现代码：

// euv.js
/**
 * 观察某个对象的所有属性
 * @param {Object} obj
 */
function observe(obj) {
  for (const key in obj) {
    let internalValue = obj[key];
    let funcs = [];
    Object.defineProperty(obj, key, {
      get: function () {
        //  依赖收集，记录：是哪个函数在用我
        if (window.__func && !funcs.includes(window.__func)) {
          funcs.push(window.__func);
        }
        return internalValue;
      },
      set: function (val) {
        internalValue = val;
        // 派发更新，运行：执行用我的函数
        for (var i = 0; i < funcs.length; i++) {
          funcs[i]();
        }
      },
    });
  }
}

function autorun(fn) {
  window.__func = fn;
  fn();
  window.__func = null;
}

// index.js
var user = {
  name: '有骨气',
  birth: '1998-4-7',
};

observe(user); // 观察

// 显示姓氏
function showFirstName() {
  document.querySelector('#firstName').textContent = '姓：' + user.name[0];
}

// 显示名字
function showLastName() {
  document.querySelector('#lastName').textContent = '名：' + user.name.slice(1);
}

// 显示年龄
function showAge() {
  var birthday = new Date(user.birth);
  var today = new Date();
  today.setHours(0), today.setMinutes(0), today.setMilliseconds(0);
  thisYearBirthday = new Date(
    today.getFullYear(),
    birthday.getMonth(),
    birthday.getDate()
  );
  var age = today.getFullYear() - birthday.getFullYear();
  if (today.getTime() < thisYearBirthday.getTime()) {
    age--;
  }
  document.querySelector('#age').textContent = '年龄：' + age;
}
autorun(showFirstName);
autorun(showLastName);
autorun(showAge);

2. 原理

vue2响应式原理简单来说就是vue官网上的这图片

通过 Object.defineProperty 遍历对象的每一个属性，把每一个属性变成一个 getter 和 setter 函数，读取属性的时候调用 getter，给属性赋值的时候就会调用 setter.

当运行 render 函数的时候,发现用到了响应式数据，这时候就会运行 getter 函数，然后 watcher（发布订阅）就会记录下来。当响应式数据发生变化的时候，就会调用 setter 函数，watcher 就会再记录下来这次的变化，然后通知 render 函数，数据发生了变化，然后就会重新运行 render 函数，重新生成虚拟 dom 树。

3. 深入了解

我们要明白，响应式的最终目标：是当对象本身或对象属性发生变化时，会运行一些函数，最常见的就是 render 函数。不是只有 render，只要数据发生了变化后运行了一些函数，就是响应式,比如 watch。

在具体实现上，vue 采用了几个核心部件:

1. Observer

2. Dep

3. Watcher

4. Scheduler

4. Observer

observer 要实现的目标非常简单，就是把一个普通的对象转换成响应式的对象

为了实现这一点，observer 把对象的每个属性通过 object.defineProperty 转换为带有 getter 和 setter 的属性，这样一来，当访问或者设置属性时，vue 就会有机会做一些别的事情。

在组件的生命周期中，这件事发生在 beforeCreate 之后，create 之前。

具体实现上，他会递归遍历对象的所有属性，以完成深度的属性转换。

但是由于遍历只能遍历到对象的当前属性，无法监测到将来动态添加或者删除的属性，因此 vue 提供了$set和$delete 两个实例方法，但是 vue 并不提倡这样使用，我讲到 dep 的时候我再说为什么。

对于数组的话，vue 会更改它的隐式原型，之所以这样做是因为 vue 需要监听那些可能改变数组内容的方法。

数组 --> vue 自定义的对象 --> Array.prototype

总之，observer 的目标，就是要让一个对象，它属性的读取，赋值，内部数组的变化都要能够被 vue 感知到。

4.1. 手动转换响应式对象

Vue提供了静态方法：Vue.observable() 手动将普通对象转为响应式对象。

var obj = {
    a: 1,
    b: 2,
    c: {
        d: 3,
        e: 4
    },
    f: [
        {
            a: 1,
            b: 2
        },
        3, 4, 5, 6
    ]
}

// 利用Vue提供的静态方法 .observable, 将一个普通对象转化为响应式对象
var reactiveObj = Vue.observable(obj)
console.log(reactiveObj)

4.2. data

Vue不允许动态添加根级响应式属性，所以需要在组件实例化之前通过配置中的 data 字段，声明所有根级响应式属性，哪怕属性值为 null。由此带来的好处有：

1. 更易于维护： data对象就像组件的状态结构（schema）, 提前声明所有响应式属性，后期有助于开发者理解和修改组件逻辑。
2. 消除了在依赖项跟踪系统中的一类边界情况。
3. 使Vue实例能够更好的配合类型检查系统工作。

4.3. 「动态添加或删除属性」

由于Vue会在初始化实例时，对所有属性（配置里 data 中存在的属性）执行 getter/setter 的转化。

那么对于 「动态添加或删除」 的属性，Vue是无法自动检查其变化。

因此，Vue提供了以下方式来手动完成响应式数据。

1. 添加：「Vue.set(target, key, val)」 或 「this.$set(target, key, val)」
2. 删除：「Vue.delete(target, key)」 或 「this.$delete(target, key)」
3. 批量操作：this.reactiveObj = Object.assign({}, this.reactiveObj, obj)

举个例子：

<template>
    <div class="demo-wrapper">
        <p>obj.a -> {{ obj.a }}， obj.b -> {{ obj.b }}</p>

        <!-- 非响应式式数据操作 -->
        <!-- 
            <button @click="obj.b = 2">add obj.b</button>
            <button @click="delete obj.a">delete obj.a</button>
        -->
        <!-- 响应式数据操作 -->
        <button @click="$set(obj, 'b', 2)">add obj.b</button>
        &nbsp;
        <button @click="$delete(obj, 'a')">delete obj.a</button>
    </div>
</template>

<script>
export default {
    data() {
        return {
            obj: {
                a: 1,
            },
        };
    },
};
</script>

4.4. 「关于数组」

由于js的限制， Vue不能检测到以下数组变动：

1. 当利用索引直接改变数组项时， 例如：vm.arr[idx] = newValue
2. 当修改数组长度时 ，例如： vm.arr.length = newLength

举个例子：

<script>
export default {
    data() {
        return {
            arr: [1, 2, 3, 4],
        };
    },
    created() {
        window.lesson4 = this;
    },
    mounted() {
        this.arr[0] = 8; // 不是响应式的
        this.arr.length = 2; //不是响应式的
    }
};
</script>

为了让上述数组操作具有响应式，采用以下方法处理：

<script>
export default {
    data() {
        return {
            arr: [1, 2, 3, 4],
        };
    },
    created() {
        window.lesson4 = this;
    },
    mounted() {
				// 操作一：通过索引修改数组项
        this.$set(arr, 0, 8); // 响应式的
        // 或
        Vue.set(arr, 0, 8);  // 响应式的
        // 或
        this.arr.splice(0, 1, 8) //响应式的
      
        // 操作二：修改数组长度为2
        this.arr.splice(2) // 响应式的
    }
};
</script>

除了可以通过静态方法 Vue.set() 和 实例方法 this.$set() 响应式的修改数组项的值。还可以使用数组方法 - splice() 。

因为，Vue对一些可以改变数组自身内容的操作API，如：splice()、sort()、push()、pop()、reverse()、shift()、unshift() 等进行了拦截和重写。从而在开发者使用这些API时，可以触发响应式数据，进而更新视图。

<script>
  export default{
    data() {
      return {
        arr: [1,2,3,4]
      }
    },
    mounted() {
      console.log(this.arr._proto_ === Array.prototype)  // => false
      console.log(this.arr._proto_._proto_ === Array.prototype)  //=> true
    }
  }
</script>

5. Dep

这里有两个问题没解决，就是读取属性时要做什么事，属性变化时又要做什么事，这个问题就得需要 dep 来解决

dep 的含义是 dependency 表示依赖的意思。

vue 会为响应式对象中的每一个属性，对象本身，数组本身创建一个 dep 实例，每个 dep 实例都可以做两件事情：

1，记录依赖：是谁在用我

2，派发更新：我变了，我要通知那些用我的人

当读取响应式对象的某一个属性时，他会进行依赖收集，有人用到了我

当改变某个属性时，他会派发更新，那些用我的人听好了，我变了

为什么尽量不要使用$set $delete ?

因为如果模板上没有用到值的话，你凭空加了一个数据,理论上来说应该不会重新运行render函数，但是上一级的dep发现自身发生改变了，所以也会导致重新运行render函数。

所以vue不建议使用$set 和$delete,最好提前先写上数据,哪怕先给数据赋值为 null;

6. watcher

这里又出现了一个问题，就是 dep 如何知道是谁在用我呢

watcher 就解决了这个问题

当函数执行的过程中，用到了响应式数据，响应式数据是无法知道是谁在用自己的

所以，我们不要直接执行函数，而是把函数交给一个 watcher 的东西去执行，watch 是一个对象，每个函数执行时都应该创建一个 watcher，通过 wacher 去执行

watcher 会创建一个全局变量，让全局变量记录当前负责执行的 watcher 等于自己，然后再去执行函数，在函数执行的过程中，如果发生了依赖记录，那么 dep 就会把这个全局变量记录下来，表示有一个 wathcer 用到了我这个属性。

当 dep 进行派发更行时，他会通知之前记录的所有 watcher，我变了。

7. Scheduler

现在还剩下最后一个问题啊，就是 dep 通知 watcher 之后，如果 wathcer 执行重新运行对应的函数，就有可能导致频繁运行，从而导致效率低下，试想，如果一个交给 watcher 的函数，它里面用到了属性 a,b,c,d,那么 a,b,c,d 都会记录依赖，然后这四个值都以此重新赋值，那么就会触发四次更新，这样显然不行啊，所以当 watcher 收到派发更新的通知后，实际上并不是立即执行，而是通过一个叫做 nextTick 的工具方法，把这些需要执行的 watcher 放到事件循环的微队列，nextTick 是通过 Promise then 来完成的。

也就是说，在响应式数据发生变化时，render 函数执行是异步的，并且在微队列中。

8. 异步更新队列

Vue侦听到数据变化，就会开启一个队列。但是组件不会立即重新渲染，而是先会缓冲在同一个事件循环中的发生的所有数据变化。此时如果同一个watcher被多次触发，只会被推入到队列中一次，这样可以「避免不必要的计算和DOM更操作」。
在下一个事件循环”tick“中， Vue刷新队列并执行实际（已去重的）工作（更新渲染）。
为此，Vue提供了异步更新的监听接口 —— Vue.nextTick(callback) 或 this.$nextTick(callback) 。当数据发生改变，异步DOM更新完成后，callback回调将被调用。开发者可以在回调中，操作更新后的DOM。

「举例1」

<script>
export default {
    data() {
        return {
            a: 1,
            b: 2,
            c: 3,
            d: 4,
        };
    },
    methods: {
        changeAllData() {
            this.$nextTick(function () {
                var pre = document.querySelector("pre");
                console.log(pre.textContent);
            });

            this.a = this.b = this.c = this.d = 10;

            this.$nextTick(function () {
                var pre = document.querySelector("pre");
                console.log(pre.textContent);
            });
        },
    },
    render(h) {
        console.log('render function')
        return h('div', [
            h('pre', `${this.a}, ${this.b}, ${this.c}, ${this.d}`),
            h('button', {
                on: {
                    click: () => {
                        this.changeAllData()
                    }
                }
            }, 'change all data')
        ])
    }
};
</script>

上例，通过一个NextTick组件的渲染，了解下 的用法。为了方便查看组件渲染时，render函数被调用的过程，在组件定义时，直接给出render函数。当点击按钮后，会在数据修改前后，使用nextTick工具方法。分别写入两个读取界面Dom的函数。结果会发现，第一个 $nextTick 回调函数获取的数据为旧数据，第二个 $nextTick回调函数获取的数据为新数据。

分析一下：

按钮点击后，异步队列的添加步骤是：

1. 第一个 $nextTick ，会将自己的回调函数（fn1）加入到当前的异步队列中。
2. 修改数据后， 经过派发更新，Scheduler会将包含了watcher队列执行逻辑的函数（fn2）加入到当前的异步队列中。
3. 第二个 $nextTick， 已将自己的回调函数（fn3）加入到当前的异步队列中。