在高速发展的互联网浪潮中，产品经理扮演着至关重要的角色，他们是连接用户、技术、市场与商业价值的枢纽。要成为一名优秀的互联网产品经理，不仅需要扎实的产品知识，更需要高超的沟通协作能力。

互联网产品的核心特性

理解互联网产品的本质是产品经理的基石。它们普遍具备以下特点：

• 敏捷开发与快速迭代：互联网产品强调“小步快跑”，通过快速发布、持续验证来适应市场变化和用户需求，不断优化。
• 用户体验至上：在激烈的市场竞争中，卓越的用户体验（UX）是产品能否吸引并留住用户的关键。这包括信息架构、交互设计和视觉设计的方方面面。
• 数据驱动决策：互联网产品从上线伊始便会产生海量数据。产品经理必须学会利用数据分析工具，解读活跃用户（DAU）、留存率、转化率、GMV等核心指标，通过数据洞察用户行为，指导产品优化。
• 规模效应与网络效应：许多互联网产品，特别是社交和平台类产品，随着用户数量的增长，其价值会呈几何级数增长，形成强大的壁垒。
• 技术依赖性：互联网产品与技术紧密相连，产品经理虽不需成为技术专家，但应具备足够的技术理解力，以便与研发团队高效沟通。
• 多元变现模式：互联网产品的盈利模式多样，如广告、订阅服务、电商佣金、增值服务等，产品经理需清晰其商业逻辑。

产品经理的核心技能

要驾驭互联网产品的复杂性，产品经理需要掌握一系列核心技能：

• 用户研究与画像：深入理解目标用户群，通过用户访谈、问卷调查等方式，构建精准的用户画像。熟悉AARRR模型（获取、激活、留存、收益、推荐），指导用户增长策略。
• 产品设计与原型：能够将抽象需求转化为具象的设计方案。熟练使用原型工具（如Figma、Sketch），进行高保真原型设计，并理解设计原则。
• 数据分析与指标解读：善用各类分析工具，从海量数据中提炼洞察，通过数据验证假设，优化产品功能。
• 竞品分析：不仅要分析竞品的功能，更要深挖其产品定位、商业模式、运营策略及优劣势，从中学习并寻找自身产品的差异化。
• 增长黑客思维：以小投入、高效率的方式实现用户增长和产品传播，将产品融入营销和增长的各个环节。
• 项目管理：在快速迭代的环境下，产品经理需具备强大的项目管理能力，有效地协调研发、设计、运营等各方资源，确保项目按计划推进。

实践与案例分析

理论学习是基础，但实践和案例分析才是提升产品能力的加速器。

• 使用与拆解产品：深入体验各类热门互联网产品，并尝试从产品经理的视角进行拆解分析：
  • 这个产品解决了什么问题？面向哪些用户？
  • 它的核心功能是什么？用户路径如何？
  • 它的商业模式是什么？
  • 有哪些值得借鉴的交互或设计？
  • 如果有机会优化，你会怎么做？
• 活跃于行业社区：加入PMCAFF、人人都是产品经理等线上社区，参与讨论，了解行业热点，从同行经验中学习。
• 关注行业报告与媒体：定期阅读权威行业报告和科技媒体，掌握最新趋势和创新案例。

互联网产品经理的沟通协作艺术

成功的互联网产品离不开高效的团队协作。产品经理作为核心枢纽，需要与研发、运营、设计团队建立信任，有效沟通，共同推动产品发展。

与研发团队的沟通协作

研发团队是产品落地的基石。产品经理需要确保：

• 需求明确性：提供清晰、完整、无歧义的 PRD（产品需求文档）或用户故事，包含功能描述、业务逻辑、异常处理、数据埋点等细节。
• 技术可行性与成本：在需求阶段就与研发充分讨论，评估技术实现难度、潜在风险及预估开发周期，避免不切实际的需求。
• 优先级：共同明确需求优先级，确保研发资源投入到最有价值的功能上。
• 进度同步与Bug管理：定期沟通项目进展，及时解决开发中的问题，并规范Bug提报和处理流程。
• 早期介入与敏捷方法：邀请研发在产品规划初期参与讨论，利用敏捷开发（如Scrum）的机制，如站会、迭代评审、回顾会，保持高效沟通和透明度。
• 技术分享与相互尊重：产品经理适度了解技术栈，理解研发挑战，并始终尊重他们的专业意见。

与运营团队的沟通协作

运营团队是产品与用户之间的桥梁。产品经理应：

• 明确产品价值与特点：确保运营充分理解产品的核心价值、目标用户和独特卖点，以便有效推广。
• 倾听用户反馈与活动需求：积极收集运营团队提供的用户反馈，并评估各类活动需求对产品的价值。
• 提供数据支持：了解运营对数据监控的需求，在产品设计中预留好数据埋点。
• 及时同步版本更新：让运营团队了解新功能和优化点，以便他们进行用户引导。
• 共同制定用户增长策略：与运营团队将产品和运营目标对齐，共同关注用户增长、活跃度、转化率等核心指标。

与设计团队的沟通协作

设计团队将抽象需求转化为具象的用户界面和交互体验。产品经理需要：

• 明确用户体验目标：清晰阐述产品解决的痛点、场景和期望的用户体验，而非直接指定设计方案。
• 提供用户画像与场景：帮助设计师理解用户需求和行为模式。
• 明确功能优先级与信息架构：与设计师共同确定合理的信息架构和页面布局。
• 遵循设计原则与规范：确保产品风格一致性。
• 迭代与评审：对设计稿进行评审，提供建设性反馈，确保设计方案符合产品和用户需求。
• 保持开放与共创：鼓励设计师发挥创意，并对他们的专业建议保持开放态度，共同关注用户反馈。

建立高效沟通协作的关键

• 清晰的沟通目标：每次沟通都应明确要解决的问题和达成的共识。
• 换位思考：理解每个团队的工作性质、目标与挑战。
• 建立信任：真诚沟通，言出必行，承担责任。
• 主动性与反馈闭环：产品经理需主动发起沟通，并确保所有反馈都有明确的接收、处理和回复机制。
• 善用工具：利用项目管理（Jira, Trello）、协作文档（Confluence）、原型（Figma）等工具提升效率。

Conclusion

洞察 设计 协作 增长

其实这个学期下来感知最大的就是，产品给我的感觉很泛，我没有去了解它的具体，只是模仿前人的状态去尽力当好一个好“产品”，泛是其职业特性决定的，产品要求从业者具备很强的通用性、学习能力和适应性。虽然概念很泛，但其核心价值始终在于发现并解决用户问题，通过产品实现商业价值。我想我也在尝试优化自己的不足，在泛泛之中能握得确切的实践经验。

上述文字是我觉得需要的几个关键点让 AI 优化了一下表述，其实如果让我说产品是什么，我不是很答得上来，但是让我慢下来梳理，我发现，它是一个很不一样的存在。

最近想开始写点关于 50projects50days 的小 demo，但是只贴代码的话未免有点太单调，如果能显示出预览页面是不是更好玩，于是在梦神提到了 iframe 可以内嵌 html 的形式，我就去想怎么可以把本地未部署的 html 代码内嵌到我的博客文章当中并且单独可以渲染互动。

步骤

step1 在 source 文件夹下新建 demo 文件夹存放我的代码文件

于是在这里可以放置我的代码文件

step2 在 hexo 的_config.yml配置文件当中修改忽略 demo 文件夹

在_config.yml配置文件里这么写：

1
2

skip_render:
  - demo/**/*

意思是告诉 Hexo：不要去渲染 source/demo/ 下的内容，而是原样复制到 public/demo/ 中。

step3 如果你的 html 是外联 css 与 js

保证引用使用 相对路径 写：

1

<link rel="stylesheet" href="./style.css">

1

<script src="./script.js"></script>

step4 在博客文章的 markdown 中直接写 iframe 可以被浏览器渲染出来

为了兼容性，最好加上 sandbox 或 allow 属性控制 iframe 权限，例如：

1
2
3
4
5

<iframe src="/demo/my-first-demo/index.html"
        width="100%" height="500"
        frameborder="0"
        sandbox="allow-scripts allow-same-origin">
</iframe>

这里的 src 替换成自己的 html 的相对路径。

step5 如果遇到渲染页面包含博客框架错误需使用hexo clean清理缓存再上传

不然就会出现像这样套娃的形式：

测试

如果不想引用 html 文件而是想直接渲染：

注意HTML 不允许 iframe 内嵌原始内容块

HTML 的 <iframe> 是一个「独立文档容器」，它 只能加载一个 URL 地址作为 src，不能直接在 iframe 标签中写入结构性的内容（比如 <h1>、<p> 等）——那种做法属于 <iframe srcdoc="...">。

直接把 HTML 内容写入 iframe 的 srcdoc 属性，代码如下：

1
2
3
4
5
6
7
8
9

<iframe 
  srcdoc="
    <div style='border:1px dashed gray; padding:1em; margin:1em 0;'>
      <h1>It works!</h1>
      <p>你可以直接把这段代码放在 Markdown 文件中。</p>
    </div>
  "
  width="100%" height="200" frameborder="0">
</iframe>

效果如下：

浏览器会渲染一个 iframe，里面显示你写的 div 和内容，没有外部引用页面。

注意：

srcdoc="..." 中的 HTML 要是 单行字符串，不能换行，属性值里的 " 要改成 ' 或使用 HTML 实体（否则 Markdown 渲染或浏览器会解析出错）。

某些老旧浏览器（如 IE）不支持 srcdoc，现代浏览器完全支持。

如果你要展示结构内容，不依赖 iframe，其实直接这样写更干净：

1
2
3
4

<div style="border:1px dashed gray; padding:1em; margin:1em 0;">
  <h1>It works!</h1>
  <p>你可以直接把这段代码放在 Markdown 文件中。</p>
</div>

效果这样：

成功嵌入预览

成功了喵，还可以在这个上面玩（）

demo

第二个 步骤器

demo

第三个 旋转导航

demo

研究了下 github desktop 确实图形化可以简化一堆 git 的命令。
把前端三剑客大致的过完了，然后想给 50projects50days 每天来一个？
还开了一点点的 go 的基础。
一些练习都上传到了我的 github 仓库里。
然后快速入门了下区块链和 web3 的知识，联系到了金融。
还写了篇稿子联系产品设计进行分享。
传送门：
Web3 产品设计的另一种打开方式

没干的

就是说给博客评论配置图床失败，后面有时间再看看喵。
高数线代大物落下了好多进度哇。
还有算法颓废，有点对这个抗拒啊喂。
还有一个月就要来的雅思还没开始准备。
后面可能就是暂且把 go 搁置，然后前端的练习，其他的方向的学习，绩点以及我的雅思还有四级。

这周的状态

其实这周的状态很糟糕我得说，之前天天熬夜还暴饮暴食，哎哎，然后整个人非常的郁闷和压力，于是乎还写了篇抱怨的博客，简直是觉得自己好无力。我喜欢把一些博客先挂着但是没学，比如 pytorch 关于机器学习那一块的，还有 sql 之类的，都是搁置的，感觉时间不够用哇诶。
还是得调整下状态，或许可以加一些运动进入到日常当中？
晚安喵。

比如家园的 hack 部分我感觉我好像做的不足，比如我的产品分享会哔哩吧啦讲了 50 分钟耗尽了心力，比如学会了在 English 和中文当中添加空格，比如我想学一些技术之类相关的东西，比如最基础的前后端或者其他感兴趣的技术，感觉都很有趣哇，但是我好累。绩点，语言成绩，技术，产品的钻研，我的娱乐就是去找好吃的，然后躺着，看天花板，然后半夜 emo，导致我的作息非常的颠倒，前两个礼拜基本上就是凌晨三四点睡的，纯粹是不知道怎么入睡，然后早 上12 点爬起来或者干脆只睡 3 个小时左右，然后上个礼拜五我就开始头痛了，然后下午的课直接请假了，很多东西都还没来得及干完，感觉一直被 ddl 赶着跑，然后我的状态很颓废。

现在的我

我现在整个人不知道怎么去排解，盯着电脑左看看右看看，然后一种酸涩与无奈就会涌上心头，然后怪罪自己为什么我不会做这些东西，为什么我这么废物，一种自负到极致的心理，看起来很变态，平时和我的聊天隐隐约约可以感受到这种心理，现在写着这篇不知道干什么的文章的时候，我正在上高数课，我就是完全人在课上但是不听讲的状态，大物，线代都是，然后作业全是抄的，但是我不能把绩点丢了，高考失利的你你愿意吗，所以我拼命这样的意义是什么，但是回过头来你拼命了什么呢我请问了。感觉阴阴的天像一块巨石压在我的胸口，我的呼吸也跟不上来，双手发抖，由不得不的怪罪自己，我到底为什么。为什么。为什么。
都没学懂我是不是很笨，什么都做不来我是不是很蠢。
我好崩溃啊
好想刀了自己
我活着干什么
是不是走了就不用忍受这样的心理了

Go 官网下载地址：https://golang.org/dl/

Go 官方镜像站（推荐）：https://golang.google.cn/dl/

IDE

vscode 或者 goland

个人是新手觉得 goland 比较省事

语法

第一个 go 程序

关于导入与使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// hello.go
package main // 程序的包名

import "fmt"
import "time"

// import语句用于引入其他包，fmt是格式化输出的包
// 也可以引入其他包，如math、strings等
// 也可以引入自定义的包，如"myapp/mypackage"
// 也可以引入多个包，如
// import (
// "fmt"
// "math"
// "strings"
// )

func main() { // 函数的{ 和函数名在同一行，否则编译错误
// main函数是程序的入口，分号可加可不加，建议是不加
fmt.Println("hello world")

time.Sleep(1 * time.Second) // 暂停1秒
}

var 变量

变量的声明
:=简短声明变量，类型自动推导对应的数据类型
:=只能在函数内部使用，不能在函数外部使用
其他的可以看看注释部分

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

// 1_test1_var.go
package main  
  
import "fmt"  
  
// 全局变量声明只能用 var 关键字  
var ga int = 100 // 全局变量声明，默认值是0  
var gb = 200  
  
// 全局变量声明，类型自动推导对应的数据类型  
// gc := 300  
// := 只能在函数内部使用，不能在函数外部使用  
  
// 四种变量声明方式  
  
func main() {  
    // 1. 声明变量 默认的值是0  
    var a int  
    fmt.Println("a =  ", a)           // Println 打印变量的值  
    fmt.Printf("type of a = %T\n", a) // %T 打印变量的类型 // Printf 格式化输出  
  
    // 2. 声明变量并赋值  
    var b int = 100  
    fmt.Println("b = ", b)  
    fmt.Printf("type of b = %T\n", b) // %T 打印变量的类型  
  
    // 3. 声明变量并赋值，类型自动推导对应的数据类型  
    var c = 200  
    fmt.Println("c = ", c)  
    fmt.Printf("type of c = %T\n", c) // %T 打印变量的类型  
  
    var cc = "abcd"  
    fmt.Printf("cc = %s, type of cc = %T\n", cc, cc) // %s 打印字符串类型的变量  
  
    // 4. 简短声明变量，类型自动推导对应的数据类型  
    d := 300 // := 是简短声明变量的方式，既初始化也赋值  
    fmt.Println("d = ", d)  
    fmt.Printf("type of d = %T\n", d) // %T 打印变量的类型  
  
    f := "abc"  
    fmt.Printf("f = %s, type of f = %T\n", f, f) // %s 打印字符串类型的变量  
  
    g := 3.14  
    fmt.Printf("g = %f, type of g = %T\n", g, g) // %f 打印浮点数类型的变量  
  
    // 打印全局变量  
    fmt.Println("ga = ", ga)  
    fmt.Printf("type of ga = %T\n", ga) // %T 打印变量的类型  
    fmt.Println("gb = ", gb)  
    fmt.Printf("type of gb = %T\n", gb) // %T 打印变量的类型  
    //fmt.Println("gc = ", gc)  
    //fmt.Printf("type of gc = %T\n", gc) // %T 打印变量的类型  
  
    // 5. 多个变量声明  
    var x, y, z int = 1, 2, 3  
    fmt.Println("x = ", x)  
    fmt.Println("y = ", y)  
    fmt.Println("z = ", z)  
  
    var xx, yy = 100, "abcde"  
    fmt.Println("xx = ", xx, "yy = ", yy)  
  
    // 6. 多行变量声明  
    var (  
       vv int  = 100  
       jj bool = true  
    )  
    fmt.Println("vv = ", vv, "jj = ", jj)  
}

常量 const 与枚举递增 iota

常量（const）声明，只读属性
const 来定义枚举类型
可以在 const() 添加关键字 iota，每行的 iota 都会累积 1，第一行 iota 的值是 0
枚举的值都符合 iota 的规则

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

// 1_test2_const.go
package main  
  
import "fmt"  
  
// const 来定义枚举类型  
//const (  
//  // 可以在 const() 添加关键字 iota，每行的 iota 都会累积 1，第一行 iota 的值是 0//  // 第二行 iota 的值是 1，第三行 iota 的值是 2//  // 以此类推  
//  // iota 只能在 const() 中使用，不能在其他地方使用  
//  BEIJING   = iota // iota = 0  
//  SHANGHAI         // iota = 1  
//  GUANGZHOU        // iota = 2  
//)  
  
const (  
    // 可以在 const() 添加关键字 iota，每行的 iota 都会累积 1，第一行 iota 的值是 0    // 第二行 iota 的值是 1，第三行 iota 的值是 2    // 以此类推  
    // iota 只能在 const() 中使用，不能在其他地方使用，只有在 const 里有累加效果  
    BEIJING   = 10 * iota // iota = 0  
    SHANGHAI              // iota = 1  
    GUANGZHOU             // iota = 2  
)  
  
const (  
    a, b = iota + 1, iota + 2  
    c, d  
    e, f  
  
    g, h = iota * 2, iota * 3  
    i, j  
    // 下面的值都符合 iota 的规则  
)  
  
func main() {  
    // 常量（const）声明，只读属性  
    const length int = 10  
  
    fmt.Println("length = ", length)  
  
    // length = 100 // 常量不能被修改  
  
    fmt.Println("BEIJING = ", BEIJING)  
    fmt.Println("SHANGHAI = ", SHANGHAI)  
    fmt.Println("GUANGZHOU = ", GUANGZHOU)  
  
    fmt.Println("a = ", a, "b = ", b)  
    fmt.Println("c = ", c, "d = ", d)  
    fmt.Println("e = ", e, "f = ", f)  
    fmt.Println("g = ", g, "h = ", h)  
    fmt.Println("i = ", i, "j = ", j)  
    // iota 的值是 0  
}

函数 function

注意返回值类型在后边，没有的话会报错
返回可以返回单个值，多个值，有形参的，也可以匿名的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

// 1_test3_function.go
package main  
  
import "fmt"  
  
// 返回单个值  
func foo1(a string, b int) int { // 注意 int 返回值在后边，没有的话会报错  
    fmt.Println("a = ", a)  
    fmt.Println("b = ", b)  
  
    c := 100  
  
    return c  
}  
  
// 返回多个值，匿名的  
func foo2(a string, b int) (int, int) { // 注意 int 返回值在后边，没有的话会报错  
    fmt.Println("a = ", a)  
    fmt.Println("b = ", b)  
  
    return 666, 777  
}  
  
// 返回多个值，有形参名称的  
func foo3(a string, b int) (c int, d int) { // 注意 int 返回值在后边，没有的话会报错  
    fmt.Println("---- foo3 ----")  
    fmt.Println("a = ", a)  
    fmt.Println("b = ", b)  
  
    // c,d 属于 foo3 的形参，返回形参变量默认初始化的值为 0    // c,d 的作用域空间是 foo3 整个函数体的{}空间  
    fmt.Println("c = ", c)  
    fmt.Println("d = ", d)  
    // 给有名称的返回值变量赋值  
    c = 100  
    d = 200  
  
    return  
}  
  
// 返回 int 共用，此写法类似 3func foo4(a string, b int) (c, d int) { // 注意 int 返回值在后边，没有的话会报错  
    fmt.Println("---- foo4 ----")  
    fmt.Println("a = ", a)  
    fmt.Println("b = ", b)  
  
    // 给有名称的返回值变量赋值  
    c = 100  
    d = 200  
  
    return  
}  
func main() {  
    c := foo1("abc", 100)  
  
    fmt.Println("c = ", c)  
  
    ret1, ret2 := foo2("111", 222)  
    fmt.Println("ret1 = ", ret1, " ret2 = ", ret2)  
  
    ret1, ret2 = foo3("abc", 100)  
    fmt.Println("ret1 = ", ret1, " ret2 = ", ret2)  
  
    ret1, ret2 = foo4("abd", 300)  
    fmt.Println("ret1 = ", ret1, " ret2 = ", ret2)  
}

import 导包路径问题

1
2
3
4
5
6
7
8
9
10
11
12
13

// lib1/lib1.go
package lib1  
  
import "fmt"  
  
// 当前lib1包提供的api  
func Lib1Test() {  
    fmt.Println("lib1Test()...")  
}  
  
func init() {  
    fmt.Println("lib1.init()...")  
}

1
2
3
4
5
6
7
8
9
10
11
12
13

// lib2/lib2.go
package lib2  
  
import "fmt"  
  
// 当前lib2包提供的api  
func Lib2Test() {  
    fmt.Println("lib2Test()...")  
}  
  
func init() {  
    fmt.Println("lib2.init()...")  
}

1
2
3
4
5
6
7
8
9
10
11

// 1_main.go
package main  
  
import (  
    "go_learning/5_init/lib1"  
    "go_learning/5_init/lib2")  
  
func main() {  
    lib1.Lib1Test()  
    lib2.Lib2Test()  
}

注意一定要有 go.mod 的存在，不然 go 会去 gopath 里找包然后报错

这里是gpt的解答：
在 Go 中，如果没有 go.mod 文件，Go 会根据 GOPATH 模式 来查找包，而不是使用 Go Modules（模块化依赖管理）。这是 Go 1.11 之前的行为，而现代 Go 项目通常推荐使用 Go Modules。

为什么没有 go.mod 会去其他路径找包？

1. 历史行为（GOPATH 模式）：

   • 在 Go Modules 引入之前（Go 1.11 之前），Go 依赖 GOPATH 环境变量来管理包。
   • 所有第三方包和本地项目都必须放在 $GOPATH/src 下，编译器会从 GOPATH 中查找包。

2. 查找顺序：

   • 如果没有 go.mod，Go 会按以下顺序查找包：
     1. 标准库（如 fmt、net/http 等，位于 GOROOT/src）。
     2. GOPATH/src 目录：尝试在 $GOPATH/src/go_learning/5_init/lib1 中查找包。
     3. 当前目录（但通常不适用，除非是相对路径导入）。

3. 你的错误信息分析：

   1	1_main.go:4:2: package go_learning/5_init/lib1 is not in std (/opt/homebrew/opt/go/libexec/src/go_learning/5_init/lib1)

   • 编译器在标准库（std）和 GOPATH 中都没找到 go_learning/5_init/lib1，因此报错。

解决方法

1. 启用 Go Modules（推荐）

在项目根目录（如 go_learning/）下运行：

1

go mod init go_learning

这会生成 go.mod 文件，之后 Go 会基于模块路径解析本地包，不再依赖 GOPATH。

2. 检查包路径

确保导入路径与模块名一致。例如：

• 如果 go.mod 声明 module go_learning，则导入应为：

  1	import "go_learning/5_init/lib1"

3. 避免依赖 GOPATH

• 现代 Go 项目应始终使用 go.mod，避免将代码放在 $GOPATH/src 下。

关键区别：GOPATH vs Go Modules

总结

• 没有 go.mod：Go 回退到 GOPATH 模式，导致编译器去 GOPATH/src 或标准库中查找包。
• 正确做法：始终使用 go mod init 初始化项目，确保依赖和本地包能被正确解析。

如果仍有问题，请检查项目结构和 go.mod 内容，或提供更多上下文进一步分析。

同时调用的方法和参数也要是大写的首字母，不然不能通过 import 调用

• 大写：允许跨包访问（类似 public）。
• 小写：仅限当前包内使用（类似 private）。

web1只读，类似于在互联网上看报刊的那种程度，典型的公司例如新浪、搜狐之类，可以阅读的一种形式。
web2是可读可写，具体一些就是可以创造内容的形式，可以点赞评论可以发表意见可以互动的形式，典型就是2004年 facebook 的诞生，后续衍生出一系列类似形式的产物，微博、b 站、抖音、知乎、滴滴等等。
如此web2就形成了一个目前互联网公司的一种商业模式：

• 免费、便宜的服务吸引用户
• 获得用户数据
• 靠推送广告赚钱
  但是这种形式多了之后，用户信息反而变得更加稀缺，互联网公司不能再局限于这种形式，于是就到了web3的形式。

基于区块链的web3

所以从web1与web2走来之后，web3基于区块链，不光可以读取信息，创造信息，还能拥有自己的信息，就好像是在网络世界里的一个独立的经济系统。
以区块链为底层架构逻辑，衍生出一整套与现实隔离的经济体系，不需要中央管理者（去中心化），而是通过自己的激励机制让它维护与运行，还可以由此自己升级，它拥有自己的货币，自己的组织形式，自己的服务模式。

加密货币

区块链自主运行，需要一个体系来激励大家自主的维护这个体系的运行，这个就是加密货币，可以把加密货币理解成区块链系统当中的一个 token（令牌）。
理解比特币，就是矿工在区块链上打包信息，维持这个区块链的运行，打包好了信息，就在交易的过程中抽取部分比特币作为奖励。
其实每个人都可以建立自己的区块链，代码也可以进行复制粘贴，每一条区块链上都会有一种加密货币，作为它的原生代币，用的人多了，认可的人多了，代币就会涨价，类似于这个区块链代表的股票，越多人认可这个区块链，这个区块链上的代币就越值钱。
由此，这个币就有了投资的属性，大家对其的相信程度，取决于背后能不能编出一套好的故事，加密货币这种东西不受中心控制，就满足了炒作的特点，同时也利用了人们不劳而获的那种心理，所以推上了风口浪尖。

交易平台

现实当中转钱或者交易股票，需要去到银行或者交易所这种地方，加密货币的市值目前很高，同时每天不计其数的交易也在发生，于是乎，交易平台应运而生。
做的比较大的就是类似币安（binance）之类的平台，同时也衍生出了一系列的市场与产品，并且树立了自己的行业地位。
同时当交易规模发展到一定地步之后，就有一些制度创新，并且生成自己的金融体系来增加币圈的货币流动性，于是，DeFi 产生了。

DeFi——Decentralized Finance 去中心化金融

它不需要像银行、券商、清算所，在中间作为中介机构，大部分创新都是把现有金融体系当中的业务搬到了币圈：

• 加密货币的借贷
• 加密货币的保险
• 加密货币的清算
• 加密货币的金融衍生品
• 杠杆交易

稳定币 Stablecoin

不论对于 DeFi 还是 web3 一个重大创新就是稳定币 Stablecoin 的出现。
加密货币有一个问题就是波动太大了，稳定币的作用就是一比一与美元绑定，相当于在web3的世界持有美元，也不用担心其价格过山车，提心吊胆的。这样不论对于投资者还是 web3 公司，都是一个非常大的激励。
一些比较大的稳定币，泰达币（Tenther) 、Coinbase 的 USDC、Binance 的 BUSD 的交易量都很高。
泰达币（Tenther）交易量远超比特币与以太坊，等等。
稳定币背后的算法也不大一样，有一些百分百与美元绑定，比如 USDC，BUSD。还有一些是算法稳定币，并不是完全抵押，存在一些风险，例如 Luna。

以太坊 Ethereum

区块链一开始好比公开账本，记录一些交易信息，而 2015 之后以太坊的出现，出现了一个叫智能合约（Smart Comtract）的东西，可以记录信息，还可以运行程序。
于是可以写出去中心化的自动运行的程序，就是去中心化应用（Decentralized Apps），也称为 DApps。（理论上可以把现有所有的 app 搬到区块链上bushi）
于是以智能合约还有区块链作为底层架构，不光是网络世界，现实世界还有很多东西都可以重构。
简而言之，去中心化的版本，把数据内容的归属权全部都归于用户自己。
不只以太坊一家，比较大的公链如 BNB Chain、Polygon、Polkadot、Cardano 之类，都相对以太坊而言有不同程度的侧重。
应用场景可以不断扩展，区块链不只是交易体系、货币机器了。

NFT Non-Fungible Token 非同质化代币

NFT 可以简单理解为数字世界的版权概念，数字技术可以复制，但是有了这个版权之后呢，就不要类似什么权威机构的认证了，也可以分清楚是谁的。
于是你可以知道：

稀缺，可以讲好品牌故事的东西，就是相当理想的投资品。

交易

虽然规模比不上上述所讲的加密货币，但是也相当的客可观，目前最大的公司也就是 OpenSea。
NFT 不光可以用来投资炒作，还可以用来产生出独一无二的数字藏品，并作为一种营销的手段，就像之前的无聊猿。只要有热度有流量就可以拉新用户与用户互动，从中获益。

游戏

web3 当中游戏和普通游戏最大的区别，拥有自己的经济体系，有自己的加密货币来作为流通货币，无论什么元素，都可以放在区块链上变成 NFT，让虚拟的系统一下变得无比真实，因为这里面的东西都可以在现实世界换真金白银，游戏越火，玩的人越多，NFT 就越值钱。（点名csgo）
出名的有 Sandbox 之类，那 web3 的游戏和元宇宙的游戏可以这么理解，元宇宙（meta）要构建在 web3 的基础之上，因为 web3 的游戏与钱那些东西挂钩，于是乎 web3 的游戏并不是纯粹的游戏，而是”赚钱“。
也叫做 GameFi。如果游戏可持续可不断交易，那就不是一个虚拟未知的庞氏骗局，反之亦然。
但是，不可置否，游戏是 web3 当中非常重要的一个部分了。

其他区块链实现的

• 区块链与物联网
  • 连接区块链与现实世界的数据
  • 去中心化的存储
    但是 web3 现实与理想差距还很远，有技术上的问题，也有人性上的问题。

人性对投机的渴望

作为普通人，我可以通过买币，拥有币来成为这些未来可能潜力巨大项目的天使投资人，这些投机的心态，让币、NFT 的价格被炒的很高。
现实当中当你有个想法创业，形成雏形、融资、发展、融资、发展循环，直到上市股票在二级市场交易，但是在 web3 当中有想法就可以立马发行属于自己的代币，直接跳过那些繁琐的步骤直接 ipo。
还没想好怎么发展，这边股票就流通炒作了，回报的速度非常之快。
比之前的互联网公司三五年的发展还要之迅速，同时会吸引大量人才涌入这个赛道，周期越短，风险越小，roi就越高。就像前文提及的加密货币的股票属性，相信的人越多，它越涨。

人才 资本 关注度

泡沫经济。
市值蒸发。
惨绝人寰。

DYOR Do Your Own Research

做好你自己的研究，在时代的风口，不要被吹跑。

区块链（Blockchain）技术源于比特币。在比特币中，为了保证每笔交易可信并不可篡改，中本聪发明了区块链，它通过后一个区块对前一个区块的引用，并以加密技术保证了区块链不可修改。
随着比特币的逐渐发展，人们发现区块链本质上其实是一个分布式的，不可篡改的数据库，天生具有可验证、可信任的特性，它不但可用于支持比特币，也可用于数字身份验证，清算业务等传统的必须由第三方介入的业务，从而降低交易成本。

比特币

比特币是一种数字货币，数字货币是基于数学加密原理构建的不可伪造的货币系统，而比特币是第一个基于数学加密原理构建的分布式数字货币系统，比特币使用区块链技术实现了数字货币的可信支付。

• 世界上最早的纸币出现在中国宋朝，称为“交子”。纸币的发行机制决定了必须由政府发行，并且强行推广使用，因此纸币又称法币。
• 电子货币本质上仍然是法币，它仍然是由央行发行，只是以计算机技术把货币以实体纸币形式的流通变成了银行计算机系统的存款。和纸币相比，电子货币具有更高的流动性。我们每天使用的网上银行、支付宝、微信支付等，都是这种方式。
• 而比特币作为一种数字货币，它和电子货币不同的是，比特币不需要一个类似银行的中央信任机构，就可以通过全球P2P网络进行发行和流通，这一点听上去有点不可思议，但比特币正是一种通过密码学理论建立的不可伪造的货币系统。

比特币解决的问题

比特币通过技术手段解决了现金电子化以后交易的清结算问题。

可以这么理解，传统的金融行业的交易是基于中央数据库的数据增减进行的，这些交易高度依赖专业的开发和运维人员，以及完善的风控机制。

总的来说，比特币具有以下特点：

• 创建了无需信任中心的货币发行机制；
• 发行数量由程序决定，无法随意修改；
• 交易账本完全公开可追溯，不可篡改；
• 密码学理论保证货币防伪造，防双花；
• 数字签名机制保证交易完整可信，不可抵赖和撤销。

即为点对点的电子现金系统。

区块链的原理

区块链就是一个不断增长的全网总账本，每个完全节点都拥有完整的区块链，并且，节点总是信任最长的区块链，伪造区块链需要拥有超过51%的全网算力。

区块链不可篡改。

区块链是由一个一个区块构成的有序链表，每一个区块都记录了一系列交易，并且，每个区块都指向前一个区块，从而形成一个链条：

每一个区块上都有唯一的哈希标识，称为区块哈希，区块通过记录上一个区块的哈希来指向上一个区块：

每一个区块上面还有Merkle哈希用来确保该区块的所有交易记录无法被篡改，区块链中的主要数据就是一系列交易，第一条交易通常是Coinbase交易，也就是矿工的挖矿奖励，后续交易都是用户的交易。

Coinbase交易是每个区块中的第一笔交易，没有输入（UTXO来源），由矿工创建，用于生成新的比特币。

比特币网络通过Coinbase交易实现货币发行，是系统中新比特币进入流通的唯一方式。Coinbase奖励需100区块确认（约16小时）后才可花费，防止双花攻击。交易哈希固定为0000000000000000000000000000000000000000000000000000000000000000。矿工可在coinbase字段添加任意信息（如创世区块包含《泰晤士报》头版标题）。

这种设计将货币发行与网络安全维护深度绑定，通过经济激励实现去中心化网络的自我维持，是比特币经济模型的核心创新之一。

哈希算法

哈希算法，又称散列算法，它是一个单向函数，可以把任意长度的输入数据转化为固定长度的输出：
$$
h = \mathbf{H}(x)
$$
我们通常用十六进制表示哈希输出。

类似的，Git 的 commit 每一次也生成的是哈希算法。

例如，对morning和bitcoin两个输入进行某种哈希运算，得到的结果是固定长度的数字：

1
2

H("morning") = c7c3169c21f1d92e9577871831d067c8
H("bitcoin") = cd5b1e4947e304476c788cd474fb579a

因为哈希算法是一个单向函数，要设计一个安全的哈希算法，就必须满足：通过输入可以很容易地计算输出，但是，反过来，通过输出无法反推输入，只能暴力穷举。

1
2

H("???????") = c7c3169c21f1d92e9577871831d067c8
H("???????") = cd5b1e4947e304476c788cd474fb579a

根据输出反推输入，只能暴力穷举。

哈希碰撞

• 安全的哈希算法要满足另外一个条件：碰撞率低。

碰撞是指，如果两个输入数据不同，却恰好计算出了相同的哈希值，那么我们说发生了碰撞。

因为输入数据长度是不固定的，所以输入数据是一个无限大的集合，而输出数据长度是固定的，所以，输出数据是一个有限的集合。把一个无限的集合中的每个元素映射到一个有限的集合，就必然存在某些不同的输入得到了相同的输出。

哈希碰撞的本质是把无限的集合映射到有限的集合时必然会产生碰撞。我们需要计算的是碰撞的概率。很显然，碰撞的概率和输出的集合大小相关。输出位数越多，输出集合就越大，碰撞率就越低。

• 安全的哈希算法满足还有一个条件：输出无规律。

输入数据任意一个bit（某个字节的某一个二进制位）的改动，会导致输出完全不同，从而让攻击者无法逐步猜测输入，只能依赖暴力穷举来破解：

1
2

H("hello-1") = 970db54ab8a93b7173cb48f55e67fd2c
H("hello-2") = 8284353b768977f05ac600baad8d3d17

关于哈希算法的作用：

如果两个输入的哈希相同，我们认为两个输入是相同的。

验证是否被篡改：

如果输入的内容就是文件内容，而两个文件的哈希相同，说明文件没有被修改过。当我们从网站上下载一个非常大的文件时，我们如何确定下载到本地的文件和官方网站发布的原始文件是完全相同，没有经过修改的呢？哈希算法就体现出了作用：我们只需要计算下载到本地的文件哈希，再和官方网站给出的哈希对比，如果一致，说明下载文件是正确的，没有经过篡改，如果不一致，则说明下载的文件肯定被篡改过。

大多数软件的官方下载页面会同时给出该文件的哈希值，以便让用户下载后验证文件是否被篡改。

和文件类似，如果两份数据的哈希相同，则几乎可以100%肯定，两份数据是相同的。

比特币使用哈希算法来保证所有交易不可修改，就是计算并记录交易的哈希，如果交易被篡改，那么哈希验证将无法通过，说明这个区块是无效的。

常用哈希算法

而比特币当中使用的两种哈希算法是 SHA-256 和 RipeMD160。

SHA-256的理论碰撞概率是：尝试2的130次方的随机输入，有99.8%的概率碰撞。注意2130是一个非常大的数字，大约是1361万亿亿亿亿。以现有的计算机的计算能力，是不可能在短期内破解的。

这里还有两种计算方式：

• 一种是对数据进行两次SHA-256计算，这种算法在比特币协议中通常被称为hash256或者dhash。
• 另一种算法是先计算SHA-256，再计算RipeMD160，这种算法在比特币协议中通常被称为hash160。

不同哈希算法计算结果：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

const
    bitcoin = require('bitcoinjs-lib'),
    createHash = require('create-hash');

function standardHash(name, data) {
    let h = createHash(name);
    return h.update(data).digest();
}

function hash160(data) {
    let h1 = standardHash('sha256', data);
    let h2 = standardHash('ripemd160', h1);
    return h2;
}

function hash256(data) {
    let h1 = standardHash('sha256', data);
    let h2 = standardHash('sha256', h1);
    return h2;
}

let s = 'bitcoin is awesome';
console.log('ripemd160 = ' + standardHash('ripemd160', s).toString('hex'));
console.log('  hash160 = ' + hash160(s).toString('hex'));
console.log('   sha256 = ' + standardHash('sha256', s).toString('hex'));
console.log('  hash256 = ' + hash256(s).toString('hex'));

计算结果如下：

1
2
3
4

ripemd160 = 46c047bd035afb64dad2293cba29994a95b8b216
  hash160 = fe56649aa4f8fdb1edf6b88d2d41f3c1f72cf431
   sha256 = 23d4a09295be678b21a5f1dceae1f634a69c1b41775f680ebf8165266471401b
  hash256 = 1c78f53758ac96f43b99ed080f36327d2a823c4df4fa094e59b006d945bbb84d

SHA-256、RipeMD160、hash256 和 hash160 的结果如上述所示。

区块链不可篡改特性

区块本身记录的主要数据就是一系列交易，所以，区块链首先要保证任何交易数据都不可修改。

Merkle Hash

在区块的头部，有一个Merkle Hash字段，它记录了本区块所有交易的Merkle Hash：

Merkle Hash是把一系列数据的哈希根据一个简单算法变成一个汇总的哈希。

假设一个区块有4个交易，我们对每个交易数据做dhash，得到4个哈希值a1，a2，a3和a4：

1
2
3
4

a1 = dhash(tx1)
a2 = dhash(tx2)
a3 = dhash(tx3)
a4 = dhash(tx4)

注意到哈希值也可以看做数据，所以可以把a1和a2拼起来，a3和a4拼起来，再计算出两个哈希值b1和b2：

最后，把b1和b2这两个哈希值拼起来，计算出最终的哈希值，这个哈希就是Merkle Hash：

但是交易不是偶数个怎么办？

只有3个交易时，第一个和第二个交易的哈希a1和a2可以拼起来算出b1，第三个交易只能算出一个哈希a3，这个时候，就把a3直接复制一份，算出b2，这样，我们也能最终计算出Merkle Hash：

如果有5个交易，我们可以看到，a5被复制了一份，以便计算出b3，随后b3也被复制了一份，以便计算出c2。总之，在每一层计算中，如果有单数，就把最后一份数据复制，最后一定能计算出Merkle Hash：

从Merkle Hash的计算方法可以得出结论：修改任意一个交易哪怕一个字节，或者交换两个交易的顺序，都会导致Merkle Hash验证失败，也就会导致这个区块本身是无效的，所以，Merkle Hash记录在区块头部，它的作用就是保证交易记录永远无法修改。

Block Hash

区块本身用Block Hash——也就是区块哈希来标识。但是，一个区块自己的区块哈希并没有记录在区块头部，而是通过计算区块头部的哈希得到的：

区块头部的Prev Hash记录了上一个区块的Block Hash，这样，可以通过Prev Hash追踪到上一个区块。

由于下一个区块的Prev Hash又会指向当前区块，这样，每个区块的Prev Hash都指向自己的上一个区块，这些区块串起来就形成了区块链。

区块链的第一个区块（又称创世区块）并没有上一个区块，因此，它的Prev Hash被设置为00000000...000。Coinbase 就这么结合起来了。

如果一个恶意的攻击者修改了一个区块中的某个交易，那么Merkle Hash验证就不会通过。所以，他只能重新计算Merkle Hash，然后把区块头的Merkle Hash也修改了。这时，我们就会发现，这个区块本身的Block Hash就变了，所以，下一个区块指向它的链接就断掉了。

由于比特币区块的哈希必须满足一个难度值，因此，攻击者必须先重新计算这个区块的Block Hash，然后，再把后续所有区块全部重新计算并且伪造出来，才能够修改整个区块链。

在后面的挖矿中，我们会看到，修改一个区块的成本就已经非常非常高了，要修改后续所有区块，这个攻击者必须掌握全网51%以上的算力才行，所以，修改区块链的难度是非常非常大的，并且，由于正常的区块链在不断增长，同样一个区块，修改它的难度会随着时间的推移而不断增加。

P2P（peer to peer）交易原理

比特币的交易是一种无需信任中介参与的P2P（Peer-to-peer）交易。就是可理解成一种点对点的交易。

传统交易需要一个中间商确保交易安全性例如银行，因为银行记录了交易双方的账户资金，能保证在一笔交易中，要么保证成功，要么交易无效，不存在一方到账而另一方没有付款的情况。

但是在比特币这种去中心化的P2P网络中，并没有一个类似银行这样的信任机构存在，要想在两个节点之间达成交易，就必须实现一种在零信任的情况下安全交易的机制。

创建交易有两种方法：

• B 和 A 希望达成一笔交易，一种创建交易的方法是 A 声称 B 给了他1万块钱，显然这是不可信的。
• B 声称他给了 A 一万块钱，只要能验证这个声明确实是 B 作出的，并且 B 真的有1万块钱，那么这笔交易就被认为是有效的。

数字签名

如何确认这个声明是 B 做出的，这就要用到数字签名，而且不可篡改。

在比特币交易中，付款方就是通过数字签名来证明自己拥有某一笔比特币，并且，要把这笔比特币转移给指定的收款方。

使用签名是为了验证某个声明确实是由某个人做出的。例如，在付款合同中签名，可以通过验证笔迹的方式核对身份。

用密码学理论设计的数字签名算法比验证笔迹更加可信。

使用数字签名时，每个人都可以自己生成一个秘钥对，这个秘钥对包含一个私钥和一个公钥：私钥被称为 Secret Key 或者 Private Key，私钥必须严格保密，不能泄漏给其他人；公钥被称为 Public Key，可以公开给任何人。

当某人想发送一个什么签名消息的时候，他可以用私钥对消息进行签名，然后，把消息、签名和自己的公钥发送出去。

其他任何人都可以通过他的公钥对这个签名进行验证，如果验证通过，可以肯定，该消息是他发出的。

所以类似在线支付、电子商务等领域，数字签名的应用有很大的作用：

• 签名不可伪造，因为私钥只有签名人自己知道，所以其他人无法伪造签名。
• 消息不可篡改，如果原始消息被人篡改了，那么对签名进行验证将失败。
• 签名不可抵赖，如果对签名进行验证通过了，那么，该消息肯定是由签名人自己发出的，他不能抵赖自己曾经发过这一条消息。

数字签名：防伪造，防篡改，防抵赖。

数字签名算法

常用的数字签名算法有：RSA算法，DSA算法和ECDSA算法。

比特币采用的签名算法是椭圆曲线签名算法：ECDSA，使用的椭圆曲线是一个已经定义好的标准曲线secp256k1：
$$
y^{2} = x^{3} + 7
$$

长这样：

比特币采用的ECDSA签名算法需要一个私钥和公钥组成的秘钥对：私钥本质上就是一个1～ $2^{256}$ 的随机数，公钥是由私钥根据ECDSA算法推算出来的，通过私钥可以很容易推算出公钥，所以不必保存公钥，但是，通过公钥无法反推私钥，只能暴力破解。

比特币的私钥是一个随机的非常大的256位整数。它的上限，确切地说，比 $2^{256}$ 要稍微小一点：

1

0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140

而比特币的公钥是根据私钥推算出的两个256位整数。

可以这么类比，公钥就是银行卡号，私钥就是银行卡密码。

但是银行卡号是确定的，密码可以修改，然而比特币私钥（密码）事先确定，然后计算出公钥（卡号），卡号是由密码通过ECDSA算法推导出来的，密码不可以更改，更改了密码之后相当于所有的东西都改了，不是原本的那一版东西了。

由于比特币账本是全网公开的，所以，任何人都可以根据公钥查询余额，但是，不知道持卡人是谁。

这就是比特币的匿名特性。

私钥不能丢失，丢失了之后里面对应的比特币也丢失了。

忘记银行卡密码可以拿身份证到银行重新设置一个密码，因为密码是存储在银行的计算机中的，而比特币的P2P网络不存在中央节点，私钥只有持有人自己知道，因此，丢失了私钥，对应的比特币就永远无法花费。如果私钥泄露，别人就可以花费对应公钥的比特币，而且无法追回。

比特币私钥的安全性在于如何生成一个安全的256位的随机数。不要试图自己想一个随机数，而是应当使用编程语言提供的安全随机数算法，但绝对不能使用伪随机数。

绝不能自己想一个私钥或者使用伪随机数创建私钥。

伪随机数

伪随机数是指通过确定性算法生成的看似随机但实际上可预测的数字序列。它们在计算机科学和统计学中广泛应用。

主要特点

1. 确定性：由算法生成，给定相同的初始条件（种子）会产生相同的序列
2. 统计特性：具有良好的统计随机性（均匀分布、独立性等）
3. 周期性：所有伪随机数生成器最终都会重复其序列

常见生成算法

1. 线性同余法 (LCG)

最简单的伪随机数生成方法，公式为：

1

Xₙ₊₁ = (a × Xₙ + c) mod m

其中Xₙ是序列中的第n个数，a、c、m是精心选择的常数。

2. 梅森旋转算法 (Mersenne Twister)

现代广泛使用的算法，特点：

• 周期极长(2^19937-1)
• 623维均匀分布
• 速度快

3. 密码学安全伪随机数生成器 (CSPRNG)

如Fortuna、Yarrow等，用于加密场景，具有：

• 不可预测性
• 即使部分序列被知道也无法推断其他部分

应用领域

• 模拟与建模
• 计算机游戏
• 数值分析
• 统计抽样
• 加密系统（需使用CSPRNG）

与真随机数的区别

在大多数计算应用中，伪随机数已足够，但在加密等安全敏感领域通常需要真随机数。

比特币钱包

比特币钱包实际上就是帮助用户管理私钥的软件。因为比特币的钱包是给普通用户使用的，它有几种分类：

• 本地钱包：是把私钥保存在本地计算机硬盘上的钱包软件，如Electrum；
• 手机钱包：和本地钱包类似，但可以直接在手机上运行，如Bitpay；
• 在线钱包：是把私钥委托给第三方在线服务商保存；
• 纸钱包：是指把私钥打印出来保存在纸上；
• 脑钱包：是指把私钥记在自己脑袋里。

不建议使用脑钱包（）

和银行账户不同，比特币网络没有账户的概念，任何人都可以从区块链查询到任意公钥对应的比特币余额，但是，并不知道这些公钥是由谁持有的，也就无法根据用户查询比特币余额。

作为用户，可以生成任意数量的私钥-公钥对，公钥是接收别人转账的地址，而私钥是花费比特币的唯一手段，钱包程序可以帮助用户管理私钥-公钥对。

交易

在区块链当中，每一个区块都至少记录了一笔交易，一笔交易就是把一定金额的比特币从一个输入转入到一个输出，实际记录的是双方的公钥地址。

当小红有两笔收入时，一笔2.0，一笔1.5，她想给小白转3.5比特币时，就不能单用一笔输出，她必须把两笔钱合起来再花掉，这种情况就是一个交易对应多个输入和1个输出：

如果存在找零，这笔交易就既包含多个输入也包含多个输出：

在实际的交易中，输入比输出要稍微大一点点，这个差额就是隐含的交易费用，交易费用会算入当前区块的矿工收入中作为矿工奖励的一部分：

计算出的交易费用：

交易费用 = 输入 - 输出 = (2.0 + 1.5) - (2.99 + 0.49) = 3.5 - 3.48 = 0.02

比特币实际的交易记录是由一系列交易构成，每一个交易都包含一个或多个输入，以及一个或多个输出。

未花费的输出被称为 UTXO：Unspent Transaction Output。

当我们要简单验证某个交易的时候，例如，对于交易f36abd，它记录的输入是3f96ab，索引号是1（索引号从0开始，0表示第一个输出，1表示第二个输出，以此类推），我们就根据3f96ab找到前面已发生的交易，再根据索引号找到对应的输出是0.5个比特币，所以，这笔交易的输入总计是0.5个比特币，输出分别是0.4个比特币和0.09个比特币，隐含的交易费用是0.01个比特币：

比特币的交易有一定的成本存在付给矿工，和银行转账手续费，即维护或者运行电子交易模式存在一定的成本异曲同工。

私钥

在比特币中，私钥本质上就是一个256位的随机整数。我们以JavaScript为例，演示如何创建比特币私钥。

在JavaScript中，内置的Number类型使用56位表示整数和浮点数，最大可表示的整数最大只有9007199254740991。其他语言如Java一般也仅提供64位的整数类型。要表示一个256位的整数，可以用数组来模拟。bitcoinjs使用bigi这个库来表示任意大小的整数。

下面的代码演示了通过ECPair创建一个新的私钥后，表示私钥的整数就是字段d，我们把它打印出来：

1
2
3
4
5
6
7
8
9

const bitcoin = require('bitcoinjs-lib');

let keyPair = bitcoin.ECPair.makeRandom();
// 打印私钥:
console.log('private key = ' + keyPair.d);
// 以十六进制打印:
console.log('hex = ' + keyPair.d.toHex());
// 补齐32位:
console.log('hex = ' + keyPair.d.toHex(32));

每次打印结果都不一样：

1
2
3

private key = 41331959824821034980258191057666381818244956280198868196301393762546465594490
hex = 5b610f6c059c45e441908d8417dcc7298027ce9b3ee53874eecc944cbb035c7a
hex = 5b610f6c059c45e441908d8417dcc7298027ce9b3ee53874eecc944cbb035c7a

随机的ECPair，每次生成的私钥都是不同的。

256位的整数通常以十六进制表示，使用toHex(32)我们可以获得一个固定64字符的十六进制字符串。注意每两个十六进制字符表示一个字节，因此，64字符的十六进制字符串表示的是32字节=256位整数。

想要记住一个256位的整数是非常困难的，并且，如果记错了其中某些位，这个记错的整数仍然是一个有效的私钥，因此，比特币有一种对私钥进行编码的方式，这种编码方式就是带校验的Base58编码。

对私钥进行Base58编码有两种方式，一种是非压缩的私钥格式，一种是压缩的私钥格式，它们分别对应非压缩的公钥格式和压缩的公钥格式。

具体地来说，==非压缩==的私钥格式是指在32字节的私钥前添加一个0x80字节前缀，得到33字节的数据，对其计算4字节的校验码，附加到最后，一共得到37字节的数据：

对这37字节的数据进行Base58编码，得到总是以5开头的字符串编码，这个字符串就是我们需要非常小心地保存的私钥地址，又称为钱包导入格式：WIF（Wallet Import Format），整个过程如下图所示（理解一下就好了，不用深入）：

可以使用wif这个库实现WIF编码：

1
2
3
4
5
6
7
8
9
10
11
12

const wif = require('wif');

// 十六进制表示的私钥:
let privateKey = '0c28fca386c7a227600b2fe50b7cae11ec86d3bf1fbe471be89827e19d72aa1d';
// 对私钥编码:
let encoded = wif.encode(
        0x80, // 0x80前缀
        Buffer.from(privateKey, 'hex'), // 转换为字节
        false // 非压缩格式
);
console.log(encoded);

打印结果如下：

1

5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ

另一种压缩格式的私钥编码方式，与非压缩格式不同的是，==压缩==的私钥格式会在32字节的私钥前后各添加一个0x80字节前缀和0x01字节后缀，共34字节的数据，对其计算4字节的校验码，附加到最后，一共得到38字节的数据：

对这38字节的数据进行Base58编码，得到总是以K或L开头的字符串编码，整个过程如下图所示：

通过代码实现压缩格式的WIF编码如下：

1
2
3
4
5
6
7
8
9
10
11

const wif = require('wif');

// 十六进制表示的私钥:
let privateKey = '0c28fca386c7a227600b2fe50b7cae11ec86d3bf1fbe471be89827e19d72aa1d';
// 对私钥编码:
let encoded = wif.encode(
        0x80, // 0x80前缀
        Buffer.from(privateKey, 'hex'), // 转换为字节
        true // 压缩格式
);
console.log(encoded);

打印结果如下：

1

KwdMAjGmerYanjeui5SHS7JkmpZvVipYvB2LJGU1ZxJwYvP98617

目前，非压缩的格式几乎已经不使用了。bitcoinjs提供的ECPair总是使用压缩格式的私钥表示：

1
2
3
4
5
6
7
8
9
10

const
    bitcoin = require('bitcoinjs-lib'),
    BigInteger = require('bigi');

let
    priv = '0c28fca386c7a227600b2fe50b7cae11ec86d3bf1fbe471be89827e19d72aa1d',
    d = BigInteger.fromBuffer(Buffer.from(priv, 'hex')),
    keyPair = new bitcoin.ECPair(d);
// 打印WIF格式的私钥:
console.log(keyPair.toWIF());

第八行的 ECPair 函数就是使用压缩格式私钥，打印结果也一样：

1

KwdMAjGmerYanjeui5SHS7JkmpZvVipYvB2LJGU1ZxJwYvP98617

公钥和地址

公钥

比特币的公钥是根据私钥计算出来的。

私钥本质上是一个256位整数，记作k。根据比特币采用的ECDSA算法，可以推导出两个256位整数，记作(x, y)，这两个256位整数即为非压缩格式的公钥。

由于ECC曲线的特点，根据非压缩格式的公钥(x, y)的x实际上也可推算出y，但需要知道y的奇偶性，因此，可以根据(x, y)推算出x'，作为压缩格式的公钥。

缩格式的公钥实际上只保存x这一个256位整数，但需要根据y的奇偶性在x前面添加02或03前缀，y为偶数时添加02，否则添加03，这样，得到一个1+32=33字节的压缩格式的公钥数据，记作x'。

注意压缩格式的公钥和非压缩格式的公钥是可以互相转换的，但均不可反向推导出私钥。

非压缩格式的公钥目前已很少使用，原因是非压缩格式的公钥签名脚本数据会更长。

根据私钥推算出公钥：

1
2
3
4
5
6
7
8

const bitcoin = require('bitcoinjs-lib');

let
    wif = 'KwdMAjGmerYanjeui5SHS7JkmpZvVipYvB2LJGU1ZxJwYvP98617',
    ecPair = bitcoin.ECPair.fromWIF(wif); // 导入私钥
// 计算公钥:
let pubKey = ecPair.getPublicKeyBuffer(); // 返回Buffer对象
console.log(pubKey.toString('hex')); // 02或03开头的压缩公钥

打印结果如下：

1

2d0de0aaeaefad02b8bdc8a01a1b8b11c696bd3d66a2c5f10780d95b7df42645c

构造出ECPair对象后，即可通过getPublicKeyBuffer()以Buffer对象返回公钥数据。

地址

要特别注意，比特币的地址并不是公钥，而是公钥的哈希，即从公钥能推导出地址，但从地址不能反推公钥，因为哈希函数是单向函数。

以压缩格式的公钥为例，从公钥计算地址的方法是，首先对1+32=33字节的公钥数据进行Hash160（即先计算SHA256，再计算RipeMD160），得到20字节的哈希。然后，添加0x00前缀，得到1+20=21字节数据，再计算4字节校验码，拼在一起，总计得到1+20+4=25字节数据：

对上述25字节数据进行Base58编码，得到总是以1开头的字符串，该字符串即为比特币地址，整个过程如下：

使用JavaScript实现公钥到地址的编码如下：

1
2
3
4
5
6
7
8

const bitcoin = require('bitcoinjs-lib');

let
    publicKey = '02d0de0aaeaefad02b8bdc8a01a1b8b11c696bd3d66a2c5f10780d95b7df42645c',
    ecPair = bitcoin.ECPair.fromPublicKeyBuffer(Buffer.from(publicKey, 'hex')); // 导入公钥
// 计算地址:
let address = ecPair.getAddress();
console.log(address); // 1开头的地址

打印结果如下：

1

1LoVGDgRs9hTfTNJNuXKSpywcbdvwRXpmK

计算地址的时候，不必知道私钥，可以直接从公钥计算地址，即通过ECPair.fromPublicKeyBuffer构造一个不带私钥的ECPair即可计算出地址。

要注意，对非压缩格式的公钥和压缩格式的公钥进行哈希编码得到的地址，都是以1开头的，因此，从地址本身并无法区分出使用的是压缩格式还是非压缩格式的公钥。

以1开头的字符串地址即为比特币收款地址，可以安全地公开给任何人。

仅提供地址并不能让其他人得知公钥。通常来说，公开公钥并没有安全风险。实际上，如果某个地址上有对应的资金，要花费该资金，就需要提供公钥。如果某个地址的资金被花费过至少一次，该地址的公钥实际上就公开了。

私钥、公钥以及地址还有钱包的推导关系如下：

签名

签名算法是使用私钥签名，公钥验证的方法，对一个消息的真伪进行确认。如果一个人持有私钥，他就可以使用私钥对任意的消息进行签名，即通过私钥sk对消息message进行签名，得到signature：

1

signature = sign(message, sk);

签名的目的是为了证明，该消息确实是由持有私钥sk的人发出的，任何其他人都可以对签名进行验证。验证方法是，由私钥持有人公开对应的公钥pk，其他人用公钥pk对消息message和签名signature进行验证：

1

isValid = verify(message, signature, pk);

如果验证通过，则可以证明该消息确实是由持有私钥sk的人发出的，并且未经过篡改。

数字签名算法在电子商务、在线支付这些领域有非常重要的作用，因为它能通过密码学理论证明：

1. 签名不可伪造，因为私钥只有签名人自己知道，所以其他人无法伪造签名；
2. 消息不可篡改，如果原始消息被人篡改了，对签名进行验证将失败；
3. 签名不可抵赖，如果对签名进行验证通过了，签名人不能抵赖自己曾经发过这一条消息。

简单地说来，数字签名可以防伪造，防篡改，防抵赖。

对消息进行签名，实际上是对消息的哈希进行签名，这样可以使任意长度的消息在签名前先转换为固定长度的哈希数据。对哈希进行签名相当于保证了原始消息的不可伪造性。

我们来看看使用ECDSA如何通过私钥对消息进行签名。关键代码是通过sign()方法签名，并获取一个ECSignature对象表示签名：

1
2
3
4
5
6
7
8
9
10
11
12
13

const bitcoin = require('bitcoinjs-lib');

let
    message = 'a secret message!', // 原始消息
    hash = bitcoin.crypto.sha256(message), // 消息哈希
    wif = 'KwdMAjGmerYanjeui5SHS7JkmpZvVipYvB2LJGU1ZxJwYvP98617',
    keyPair = bitcoin.ECPair.fromWIF(wif);
// 用私钥签名:
let signature = keyPair.sign(hash).toDER(); // ECSignature对象
// 打印签名:
console.log('signature = ' + signature.toString('hex'));
// 打印公钥以便验证签名:
console.log('public key = ' + keyPair.getPublicKeyBuffer().toString('hex'));

打印结果如下：

1
2

signature = 304402205d0b6e817e01e22ba6ab19c0ab9cdbb2dbcd0612c5b8f990431dd0634f5a96530220188b989017ee7e830de581d4e0d46aa36bbe79537774d56cbe41993b3fd66686
public key = 02d0de0aaeaefad02b8bdc8a01a1b8b11c696bd3d66a2c5f10780d95b7df42645c

ECSignature对象可序列化为十六进制表示的字符串。

在获得签名、原始消息和公钥的基础上，可以对签名进行验证。验证签名需要先构造一个不含私钥的ECPair，然后调用verify()方法验证签名：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

const bitcoin = require('bitcoinjs-lib');

let signAsStr = '304402205d0b6e817e01e22ba6ab19c0'
              + 'ab9cdbb2dbcd0612c5b8f990431dd063'
              + '4f5a96530220188b989017ee7e830de5'
              + '81d4e0d46aa36bbe79537774d56cbe41'
              + '993b3fd66686'

let
    signAsBuffer = Buffer.from(signAsStr, 'hex'),
    signature = bitcoin.ECSignature.fromDER(signAsBuffer), // ECSignature对象
    message = 'a secret message!', // 原始消息
    hash = bitcoin.crypto.sha256(message), // 消息哈希
    pubKeyAsStr = '02d0de0aaeaefad02b8bdc8a01a1b8b11c696bd3d66a2c5f10780d95b7df42645c',
    pubKeyAsBuffer = Buffer.from(pubKeyAsStr, 'hex'),
    pubKeyOnly = bitcoin.ECPair.fromPublicKeyBuffer(pubKeyAsBuffer); // 从public key构造ECPair

// 验证签名:
let result = pubKeyOnly.verify(hash, signature);
console.log('Verify result: ' + result);

注意上述代码只引入了公钥，并没有引入私钥。

比特币对交易数据进行签名和对消息进行签名的原理是一样的，只是格式更加复杂。对交易签名确保了只有持有私钥的人才能够花费对应地址的资金。

想到有些时候别人看到我的博客可能会有一些想法，于是乎我就想着把博客的评论区想着怎么配置一下，之前因为没有服务器，所以我就想试试看 giscus 来配置，但是似乎登录有 github 的限制还有就是有的时候没办法链接上评论，于是乎我就试试看了 vercel+twikoo 的组合来给 butterfly 主题 hexo 博客配置评论区，下面是配置过程。

配置过程

申请 MongoDB Atlas 账号

MongoDB Atlas 是 MongoDB Inc 提供的 MongoDB 数据库托管服务。免费账户可以永久使用 500 MiB 的数据库，足够存储 Twikoo 评论使用。

注册 MongoDB Atlas
可以创建免费的数据库。

位置就在 aws 的 HK。

然后开始创建用户，点击这个 connect 就可以。

这里填写你的 username 和 password，然后点击 create database user。

然后点叉叉关掉这个页面，接下来配置 Network Access。

接下来在 Network Access 页面点击 Add IP Address 添加网络白名单。因为 Vercel 的出口地址不固定，所以我们这里 Access List Entry 输入 0.0.0.0/0（允许所有 IP 地址的连接）。

回到 clusters 这里点击 connect，然后连接方式选择 Drivers。

Driver 选择 Node.js 版本选择 6.7 or later，然后在终端安装 mongodb 数据库，将连接字符串中的 <username>:<password> 修改为刚刚创建的数据库 用户名:密码。到这里，你应该把那一段：

1

auberginewly:<db_passward>

替换成自己的：

1

username:passward

注意：连接字符串包含了连接到 MongoDB 数据库的所有信息，一旦泄露会导致评论被任何人添加、修改、删除，并有可能获取你的 SMTP、图床 token 等信息。请妥善记录这一字符串，之后需要填入到 Twikoo 的部署平台里。

在 vercel 里部署 twikoo

传送门一键部署 twikoo 到 vercel

要确保之前没有这个仓库叫这个名字，不然会有冲突。

等待部署一会。

然后我们来添加环境变量 MONGODB_URI，这里我们进入 settings 的 environment variables 里面进行设置。

key 值设置 MONGODB_URI，value 值就设置之前复制的那一串：

然后添加完毕，点击 save，进入到 deployment protection，把 vercel authentication 设置成 disabled。

然后进入到 deployments 这里，进行 redeploy，等待重新部署完毕，就可以了。

然后就会显示：

云函数运行正常，然后我们可以进行下一步接入 hexo 了。

记得保存自己的 vercel domain，在这里：

接入 hexo

打开 butterfly 主题的配置文件_config.yml，找到comments，然后按照如下图修改：

把 use 修改为 Twikoo。

然后找到 twikoo 模块，按照下面修改配置：

envId 就是上面说的 vercel domain 部分，复制过来就好了，注意 yml 文件配置，冒号与后边的配置信息必须有一个空格的间隔，不然会报错。还有 visitor 应该修改为 true，我这里有点问题。

然后重启 hexo，就可以看到评论区了耶。

1
2

hexo g
hexo d

效果如图

配置完毕

后续可以看看怎么个其他方式的优化，因为我这里是没有自己的服务器所以选择使用 vercel，还有 mangodb 数据库免费的 512 mb 对于评论区完全够用了，希望能帮助到你。

blog

给博客配置了静态域名和rss订阅，可以看看我之前的文章。

学习

详细深入了解了一下git的用法和github关联，就是github desktop和gitee俩远程库那种的推送还没了解详细，可以看看之前的文章。
本来想开sql的学习，奈何发现时间不大够。
还有课内摆了没怎么学，哎，要考大物了，继续突击，下礼拜要好好把课内捡回来了。

大创结稿

赶稿与ppt终于改了一版又一版，截稿等待结果咯。

后续想干的

写完cursor使用指北。
quickstart in pytorch机器学习深度学习及其方向。
前后端基础的学习，与产品去中心化的分享。

官网 https://www.cursor.com/cn

终端启动配置

因为我之前有设置.code或者code启动vscode，所以这边是设置了cursor来快捷启动cursor。

安装中文插件

核心功能

tab补全

光标预测，tab补全。

agent/ask/manualk

Cursor 是一个为程序员设计的 AI 编程编辑器，它的 agent/ask/manual 模式，是三种不同的交互方式，用来控制 AI 如何与你的代码协作。下面是这三种模式的区别和用途：

🧠 1. agent 模式（自动代理模式）

作用：AI 自动分析并主动修改代码，像“自动驾驶”。

• 你只需要输入一句目标（如“优化这段代码的性能”），它会自动扫描当前文件甚至项目上下文，判断应该怎么改，然后直接帮你修改代码。
• 适合你信任 AI、希望它自己动手的情况。

典型用途：

• 重构一段复杂代码
• 修复 bug
• 实现一个小功能
• 自动写测试代码

💬 2. ask 模式（提问模式）

作用：AI 像“答疑助手”，它不会修改代码，只会回答问题或解释。

• 你问：“这段代码是干嘛的？” 它就解释。
• 你说：“帮我写个 for 循环模板。” 它就写个代码片段出来，不会动你当前文件。
• 你自己决定要不要把回答贴进去。

典型用途：

• 看不懂别人的代码，想请 AI 翻译
• 想让它列出一个实现思路、代码片段，但不想让它自动改项目

✍️ 3. manual 模式（手动模式）

作用：你自己选中代码片段，告诉 AI 应该改哪里，它只看你选中的部分**。**

• AI 只分析你手动选择的代码块，不会读整个文件上下文，修改范围也有限。
• 修改建议出来后，你手动选择是否替换原代码。

适合：

• 小范围快速编辑
• 对 AI 不太放心、怕它“乱动”时
• 做精准控制，比如“只改这个函数，不动别的”

简单总结：

如果你正在用 Cursor 写代码，建议：

• 熟悉 ask 模式，随时提问查资料
• 用 manual 模式做小改动
• 用 agent 模式快速完成重复、结构性任务（比如“把这段代码转成 TypeScript”）

快捷键

cmd+I agent模式
cmd+L ask模式

模型推荐

综合领域问答理解 ask

gpt-4o

代码 agent暂时只支持Claude模型

claude 3.7 sonnet
gemini 2.5 pro

复杂功能拆解，一步步喂给agent，提取上下文，还可以运行一些终端的命令之类。
简单功能问ask就好了，速度快一些。

关于@菜单

• 文件/文件夹
• 代码
• 文档
• Git
• 历史对话
• cursor规则
• 终端
• Linter errors
• Linting 指的是通过专用的分析软件对 源代码 进行分析，查找出源代码中存在的语法和样式错误的过程。

Docs文档

可以添加链接然后存文档

输入链接

即可

注意引用文档的不同。
例如 https://docs.cursor.com/ 会引用当前这个页面的文档及其子文档，但 https://docs.cursor.com 只会引用当前的文档。
就是最后一个斜杠有无的区别。

临时链接解析上下文可以直接@+链接地址

于是我开始思考，人可以感受多少个夏天。

偶然葱郁的绿荫和夏至未至的前奏突然响起，会有一种淡淡的遗憾映入眼帘，然后我开始思考，人到底能感受多少个夏天，在太阳升顶的午后，长夏默默，什么话也不说，就这样和眩晕的白昼对坐，绿色翻涌成夏，每每的四月开始翻涌的热浪，某一刻，内心就会被一种名为夏天的感受填满。

对于中国孩子的夏天。

关于夏天的特殊情结，要从十几岁的每次升学的毕业说起，在每年冬日过后，随着白昼的慢慢拉长，温度的慢慢攀升，像蜿蜒的爬山虎，在某一刻透出最苍翠的绿色，撒下属于它的那一片阴翳，每一次夏天夏天的悄悄靠近，都在一些重要的节点，小升初，中考，高考，毕业，18岁之前的每一个重大的转折，三年之约，好像都在某一个回忆深刻的夏天。

还记得20年6月某天晚自习的傍晚，霞光的层次分明鲜艳，那年初二，还没什么其他的顾虑，就是写写题目，聊聊天，坐在操场上畅想明媚的未来，一切都好像刚刚开始，一切都好像还来得及，有明确的目标，和想象里光明的以后。

那天的晚霞belike：

于是呀，在每一年的夏天，随着风扇呼呼的转动，压力和温度一并升高，每天照例的晚自习和考试，偶尔汗浸透了试卷的一角，字迹随着化开，闷热的空气被带着流动起来，我们都为着同一个目标不断前行，在无数重复的日夜里得以觅见点点星光，在重复的罅隙当中试图全力揭开最后那个属于自己的答案。

那些夏天，西瓜，汽水，冰棒，空调，风扇。

蝉鸣，白云，晚风，小巷。

好像每个夏天都有几次闷热，几场暴雨，几次毫无防备的炙烤，对于十几岁夏天详细的记忆已经不清晰了，它不再真切，好像所有的经历的一切都是一场幻觉，但是都停留在海马体的记忆当中，每每想起那种感觉，就像是午后在老式的小巷里，摇椅上，阳光稀稀落落透过密密麻麻的树叶，闪着斑斑点点的摇曳的光晕，偶尔的几声狗吠，小卖部老板的蒲扇，一切慢下来，一切富有生机，好像，都在向上走。

去年高考完了，没很理想，那个夏天是把自己关禁闭的，很多时候都在胡思乱想，要是回到高考前几天，是不是就可以考好一点呢，万一重来，重来就好了。

夏天的爱太没天赋，稍有不慎就炙烤万物。

有的时候晴空万里，有的时候乌云密布，然后暴雨如瀑，长夜散尽，又热烈如初。人好像总是在不断试错的过程当中成长的，还没学会细水长流，还没学会如何留白，白天总是发呆，夜晚总是焦虑空洞，我在这个专业，是不是不合适，好像总是学不懂那些高深的技术，一切都是那么的新奇与未知，一次次的受挫与熬夜，把曾经那个少年意气风发的棱角消磨殆尽，湮灭消失。没有切实的目的，对于工作与求学的迷茫，如同夏日的晚风，来回吹拂，但它并不停留。

人生是旷野，不是轨道。

高中作文常常引用的一句话，其实至今也没明白它深层的内核。但是19岁大一的我会时时刻刻想，为什么我会这么累。回头看看自己干了什么，提笔就是虚无。每天忙忙碌碌，但是精神是低迷的，完全没有中学时代的那股干劲和毅力，那段时间，我怀念的，是那种确定性带来的安全感，一切都安排好了，桌上的课程表，起起伏伏的月考成绩，统一的下课铃声，亘古不变的周测，就连烦恼也是标准的：怎么我又考砸了，今天又没买到好吃的…像是一列按照轨道行进的火车，轰隆轰隆，朝着目的地慢慢前进。

但是现在，我被丢到了荒野上。就业？读研？摆烂？入党？卷技术？卷绩点？各种比赛？学不懂的算法？或者追求喜爱的东西？评判的标准多样化，必须舍弃一些东西，但是带着高中的学生思维，我竟然迷茫了，我真的喜欢这个专业吗，我真的适合这个专业吗，我拼命的去争取，绩点，比赛，入党，看起来十分的可笑，就像在跑步机上不断的狂奔，回看发现自己停留在原地不动。

真的很搞笑。

我想回高中。

汗流浃背，但是什么都没获得。

1
2
3

# 我想回到那个目标明确的日子
# 我想有人替我做决定
# 我想再体验一次'只要听话就能被夸奖'的简单逻辑

困住我的，不是大学，是那个还在用高中规则玩游戏的自己，是还没转变的学生思维，是沉浸在高考考砸道心破碎一心保研的自己。我还在等待那份标准答案，等待谁给我发的人生考卷，仿佛还可以像从前那样，用中性笔在泛黄的考卷上狠狠的写下解，然后酣畅淋漓的推算，那些在梦中的数学大题，物理题，可是啊少年，成年的世界没有统一的命题，也没有监考老师，这些既是残酷，也是浪漫。

高中的好学生，也要是叛逆的少年，那些好学生的品质，你该抛弃了。你现在需要的是，在没人督促的时候寻找方向，在志愿落空，考砸的时候，不再把高考的失败作为失败，重新定义成功，或者允许自己暂时当一个逃兵，躺平一段时间，思考我为什么会焦虑列出我到底应该干什么。

或许，我们从来就不是想回到过去，只是还没学会享受这种失控的自由。

那个在数学试卷上写下解和密密麻麻工工整整步骤的女孩，现在需要更大的勇气，在某处写下我的未来我做主和我应该干什么。
后面跟着什么都行，我要点奶茶发呆一会 我要去散散心 为什么不可以呢？

大概，夏季与我们的生命曾经真的是同一质地。

许许多多虚无缥缈的东西，都是旁枝末节，都是那些，午后睡醒睡眼惺忪越想越淡的梦境。最后，还是回归当下，做一些切实的事情，过具体的日子，在什么时候就去做属于自己的事情，过去的就让他过去吧，无论是好是坏，它都是你人生当中不可或缺的经历，未来的时候回望现在，也显得弥足珍贵呢。夏天的任务就是过完夏天，享受蝉鸣，绿叶，鲜花，骄阳，白云，长长的散步，微风掠过的发梢，让日子按部就班的进行，让命运温柔的推动自己前进，每天一点点的进步，就很厉害了呀。

人生的考场早就换了试卷，但是我还握着已经写完的铅笔。

窗外的绿色沙沙作响，4月中旬的30度和赶不完的ddl，近代史课躲在抽屉里写的博客，是属于我的大学的第一个初夏。

关于夏天 ABOUT SUMMER

在这个下午的小记，耳机里的夏至未至，总带着一些遗憾与淡淡的平静，把一些放下，暂时性的逃离吧。

叹口气，继续前行啦。加油呀。
拍张照吧，3、2、1，茄子！
2025/初夏/thoughts

突然某学长晚上提到关于rss订阅，以前还没了解过这个东西，于是迅速的了解了一下，RSS 的全称是 Really Simple Syndication（简易信息聚合），它是一种消息来源的格式规范，网站可以按照这种格式规范提供文章的标题、摘要、全文等信息给订阅用户，用户可以通过订阅不同网站 RSS 链接的方式将不同的信息源进行聚合，在一个工具里阅读这些内容。

简单来说，RSS 就是一种订阅某个网站内容更新的协议。这种略显「古老」的协议在社交媒体和聚合阅读的冲击下日渐式微，大多数人都不知道这个东西的存在了，更者在算法推荐为各大厂商盈利的当下，rss的订阅显得有那么一些反算法。

但是rss的阅读精简模式可以让我们专注于想要阅读的内容，在信息裹挟的洪流下可以精准迅速的获得想要的内容，像是一种在pick的过程，捣鼓捣鼓还是很好玩的。

配置步骤

step1 下载hexo支持的rss插件

hexo的rss插件，叫hexo-generator-feed，在hexo文件夹终端下载插件

1

npm install hexo-generator-feed --save

step2 根目录配置

然后在根目录中的_config.yml中添加如下配置

1
2
3
4
5

feed:  
  enable: true  
  type: atom  
  path: atom.xml  
  limit: 0

官网还说明了一些其他的参数，如：

• enable: 默认开启可以省略
• type: RSS的类型(atom/rss2)
• path: 文件路径，默认是 atom.xml/rss2.xml
• limit: 展示文章的数量,使用 0 或则 false 代表展示全部
• hub: 如果使用不到可以为空
• content: （可选）设置 true 可以在 RSS 文件中包含文章全部内容，默认：false
• content_limit: （可选）摘要中使用的帖子内容的默认长度。 仅在内容设置为false且未显示自定义帖子描述时才使用。
• content_limit_delim :（可选）如果content_limit用于缩短帖子内容，则仅在达到字符限制之前在此分隔符的最后一次出现处剪切。默认不使用。
• icon: (可选）自定义图标。默认为主配置中指定的电子邮件头像。
• autodiscovery: 添加提要自动发现，默认开启
• template : 自定义模板路径。该文件用于生成 xml 文件

step3 主题配置

然后去主题的_config.yml中添加配置

1

rss: /atom.xml

这样你在用hexo g生成静态网页的时候会在public文件夹中（也就是你静态网页文件夹中）生成一个rss2.xml文件

step4 添加主页rss按钮（可选）

如果你想让别人知道你的RSS链接，可以在主题中的social中添加如下配置（就是在那侧边栏个人资料下面添加一个图标并链接到你的RSS文件）

1

fas fa-rss: /atom.xml || RSS || '#ee802f'

并且添加了rss的橘黄配色（）

re

好晚了，迅速结束配置，过几天再来捣鼓rss阅读器，感觉很好玩的样子ahh

在我昨天给博客绑定一个自己的域名之后，我发现每次写完文章进行部署上传的时候，执行以下命令之后:

1
2

hexo d
hexo g

用auberginewly.site访问不了我的博客，然后就去设置里githubpages查看，发现我绑定的domain被清空了，这就导致每次部署上传之后我都要手动与自己的域名绑定，相当的麻烦，于是我想着怎么解决下这个问题，顺便实现了下怎么样去简化部署的命令，下面是步骤。

为什么绑定的domain会被清空？

大概率是 Hexo 每次部署（hexo g && hexo d）的时候，把 GitHub Pages 仓库里的 CNAME文件覆盖或删除了，导致绑定的自定义域名（如 auberginewly.site）失效。

背景小科普

GitHub Pages 绑定自定义域名时，会在你的仓库根目录生成一个名为 CNAME 的文件，里面只写着你的域名（如 auberginewly.site）。如果这个文件被删除或不在部署后的文件夹中，域名就会失效。

解决方法

进入你的 Hexo 项目目录

1

cd your-hexo-folder

创建一个 source/CNAME 文件，内容是auberginewly.site(替换成你自己的域名)

1

echo 'auberginewly.site' > source/CNAME

确保 .gitignore 没有忽略 CNAME 文件。
然后执行：

1
2
3

hexo clean
hexo g
hexo d

这样 Hexo 每次生成静态文件时都会把 CNAME 文件一并部署上去，GitHub Pages 的绑定就不会断了，也不用费劲心思的每次手动部署了。

自动化脚本简化hexo部署

如果你想让 Hexo 部署流程更加自动化，避免每次都手动确认和添加 CNAME 文件，可以通过编写一个简单的自动化脚本来实现。下面是步骤：

创建部署脚本

在 Hexo 项目根目录创建一个 deploy.sh 脚本文件：

1

touch deploy.sh

我的系统是macos，如果是windows的话应该是deploy.bat脚本文件，取决于不同的操作系统，我的脚本如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

#!/bin/bash

# 切换到 Hexo 项目根目录
cd "$(dirname "$0")"

# 确保 CNAME 文件存在
if [ ! -f source/CNAME ]; then
    echo "auberginewly.site" > source/CNAME
    echo "CNAME 文件已自动创建"
fi

# 执行 Hexo 构建和部署
echo "开始构建和部署..."
npx hexo g
npx hexo d

# 部署完成后，只清理 public 文件夹，保留 db.json
echo "部署完成，开始删除 public 目录..."
rm -rf public

echo "部署和清理完成！"

因为不会nano编辑器，我直接选择在文本里编辑，可以使用vim或者nano编辑器进行命令行的编辑：

1
2
3

# 可以进行选择的使用
nano deploy.sh # nano
vi deploy.sh # vim

赋予脚本执行权限(linux或者macos适用)

如果你在 Linux 或 macOS 上，可以通过以下命令赋予脚本执行权限：

1

chmod +x deploy.sh

然后你就可以运行 ./deploy.sh 来完成部署。

简化部署过程

每次你运行 ./deploy.sh，它会先检查 CNAME 文件是否存在，如果不存在会自动创建，然后再进行构建和部署。这样你就不用每次都担心 CNAME 文件的问题，整个流程更为流畅。

进一步简化——使用 alias 命令简化

可以在你的 macOS 上创建一个 命令别名，使得每次部署只需要一个简单的命令。

打开你的终端配置文件（例如 .bash_profile 或 .zshrc，具体取决于你使用的 shell）

我这里的是.zshrc，使用命令打开文件（我这里是使用zsh）：

1

nano ~/.zshrc

有小朋友要问了，zsh是什么？？

关于zsh

Zsh（Z Shell）是一种功能强大的Unix shell，它是Bash（Bourne Again Shell）的一种替代品，并且在许多方面有所增强。Zsh 提供了丰富的功能，包括：

1. 自动补全：Zsh 能够智能地完成命令、文件路径、命令参数等的自动补全，比 Bash 更加灵活。

2. 插件和主题支持：Zsh 允许用户安装插件和主题，常见的插件管理器是 oh-my-zsh，它大大增强了 Zsh 的可用性和外观。

3. 高级路径展开：Zsh 具有强大的文件路径和通配符扩展功能。

4. 历史管理：Zsh 能够更加智能地管理命令历史，并支持在历史中查找和搜索。

5. 自定义功能：Zsh 支持高度的自定义，包括快捷键、变量、命令别名等。

6. 更多的内建命令和选项：Zsh 提供了许多内建命令，能够更方便地进行文件操作、字符串处理等。

由于其易用性和强大功能，Zsh 成为很多开发者和系统管理员的首选shell之一。

修改或添加 hexo 别名

修改或添加以下行来让 hexo 成为你的部署命令：

1

alias hexo="cd ~/your-hexo-folder && ./deploy.sh"

记得将 ~/your-hexo-folder 替换成你实际的 Hexo 项目路径喔。

保存并加载配置

保存后，通过以下命令让修改生效：

1

source ~/.zshrc

于是你得到了

如果设置了 alias hexo，你只需在任何地方输入：

1

hexo

它就会自动的进入到hexo的根目录当中并进行部署上传（记得把魔法关了）。

一个小问题

但是我这样简化部署上传流程之后，发现我想创建新markdown博客的时候，这个命令:

1

hexo new "your-post-name"

它失效了，不会帮我在_post目录下创建新的文档而是运行deploy的脚本，我找了半天也没想到怎么解决，要么就把之前简化的步骤全删了，然后我就了解到了这个：

执行npx命令

使用 npx 来确保使用的是当前项目中安装的 Hexo，而不是全局安装的 Hexo。这样能够避免由于路径问题造成的执行错误。

关于npx

在使用 Hexo 时，npx 和全局安装的 hexo 命令之间有一些区别，下面详细解释它们的工作原理和为什么使用 npx 可以帮助避免一些潜在问题。

1. npx 命令：

• npx 是一个来自 npm 的命令行工具，它通常用于执行在 node_modules 目录中的本地依赖包，或者在没有全局安装的情况下直接执行某个命令。
• 当你运行 npx hexo 时，它会优先执行 项目本地安装 的 Hexo 版本（即项目中的 node_modules/hexo），如果没有安装本地 Hexo，它会尝试下载并执行它。
• npx 会确保你使用的是项目特定版本的 Hexo，而不是全局安装的 Hexo。这样，你的项目始终使用与项目配置兼容的 Hexo 版本，避免因为版本不匹配而导致问题。

2. 全局安装的 hexo 命令：

• 如果你使用全局安装的 Hexo，执行 hexo 命令时，它会使用全局安装的 Hexo 版本（即通过 npm install -g hexo-cli 安装的版本）。
• 全局安装的 Hexo 可能与项目中的 Hexo 版本不同，尤其是当你在不同的项目中使用 Hexo 时，全局安装的 Hexo 可能不是项目所需的特定版本。
• 这样可能会导致一些版本兼容性问题，尤其是在使用特定插件或者不同 Hexo 版本时。

区别总结：

• 使用 npx hexo：确保使用的是当前项目中的 Hexo 版本（从 node_modules 目录中读取）。这样可以避免因为全局安装的 Hexo 版本不同而导致的潜在问题。
• 使用全局安装的 hexo 命令：使用的是全局安装的 Hexo 版本，这可能与项目中的版本不同，导致不一致或者不兼容的情况。

为什么使用 npx hexo 更好？

1. 版本一致性：npx hexo 确保每次执行命令时都使用与项目相同版本的 Hexo，避免全局安装的 Hexo 版本不同步的问题。
2. 避免路径问题：有时全局安装的 Hexo 路径可能不对，尤其是在你使用多个项目时。npx 会确保命令从项目根目录中的 node_modules 目录执行，避免了路径配置错误的风险。
3. 无需全局安装 Hexo：如果你的项目中有本地安装 Hexo，就不需要全局安装它，避免了全局和局部依赖的冲突。

实际操作：

如果你有一个 Hexo 项目，并且在项目目录中执行 npx hexo new "test-post"，它会使用项目中的 Hexo 版本创建一个新文章。如果你使用全局安装的 hexo new，它可能会使用不同版本的 Hexo，这可能导致意外的行为，特别是当你升级或更改项目 Hexo 配置时。因此，推荐使用 npx，确保每次都使用与项目相匹配的 Hexo 版本。

所以解决方式如下

就是每次在hexo new "page"前加上一个npx，使用项目中的 Hexo 版本创建一个新文章，避免与脚本的冲突产生。

关于删除脚本

我之前发现了上面的那个问题之后，直接把deploy.sh丢到废纸篓里，结果发现hexo、hexo d、hexo g、hexo new "pages"这些命令全部失效了，并且报错：

1

zsh: no such file or directory: ./deploy.sh

当前所在目录里找不到名为 deploy.sh 的文件，但执行了一个指向它的命令。说明 可能还残留了一些配置 指向这个脚本，我们一步步来解决它。

检查 .zshrc 是否还存在 alias 指向 deploy.sh

在终端输入：

1

nano ~/.zshrc

然后看看里面有没有这类语句：

1
2
3

alias deploy="./deploy.sh"
alias hexo="./deploy.sh"
alias hexo="cd ~/xxx && ./deploy.sh"

如果有，就删掉或者注释掉（在前面加 #）。
然后按 Ctrl + O 保存，Enter 确认，Ctrl + X 退出。
最后，重新加载配置：

1

source ~/.zshrc

删除 deploy.sh 别名缓存（如果之前跑过 alias）

在终端里执行下面这个命令，彻底清除当前会话里的 hexo 和 deploy 别名（如果有）：

1
2

unalias hexo
unalias deploy

如果不确定当前有没有残留 alias 设置，可以运行这个命令查一下：

1
2

alias | grep deploy
alias | grep hexo

如果还看到指向 ./deploy.sh 的 alias，那说明 alias 没清干净，需要删 .zshrc 里那一行。
可以执行这个命令之后试一下：

1

hexo d

或者用 npm 的方式：

1

npm run deploy

FINISH

至此，每次hexo部署后CNAME被清除导致域名与仓库解绑和简化hexo的部署命令的问题就解决了，所遗留的暂时性解决方案就是npx hexo new "page"，但是在此之后就不用手动添加域名了，记录一下解决问题的过程，希望对遇到相同问题的人有帮助。

• re:累了喵，吃饭去了。

因为我原来博客的默认就是github的仓库名
auberginewly.github.io
感觉没什么特色而且不科学上网无法访问
所以存在一些限制
于是想试试看配置域名和做一些加速服务（还没实现）

• 可能考虑cloudflare（过时/速度慢）或者netlify部署？

那么如何配置呢？

step1 购买属于自己的域名

购买域名的话可以去华为云，阿里云，腾讯云等等的去购买，但是都需要实名认证，我是去腾讯云上买的auberginewly.site，价格是230元/10年，感觉还挺划算（）

step2 配置DNS服务器

我是直接使用腾讯云自动推荐的

step3 进行DNS解析

这些dns是指向githubpages的，但是由于一些限制，我的域名这里只能添加两条记录，但是也可以使用。

step4 进行githubpages设置

• 打开pages
• 然后确保仓库的分支正确
• 填写你的域名
• 打开https服务
  做完这些步骤之后可能需要等待一会，因为要确认下你域名的dns，可能需要几小时不等，之后你就可以通过你的域名访问个人博客的pages了。

step5 确认

按道理来讲，一般会在仓库里生成一个纯文本文件CNAME
里面记录了你的域名

如果没有的话
可以去这里create new file

关于CNAME

好问题！我们来简单通俗地解释一下：

🌐 什么是 CNAME？

CNAME 是 Canonical Name 的缩写，中文叫“别名记录”。
它的作用是：
👉 让一个域名指向另一个域名

🧠 举个例子更好懂：

假设你在 GitHub Pages 上建了一个网站，地址是：

1

auberginewly.github.io

你买了一个自己的域名：

1

auberginewly.site

你想让大家访问 auberginewly.site 的时候，其实跳转去 GitHub 上的站点，那就要做“域名绑定”。

这时候：

• 你会在 GitHub 仓库里添加一个叫 CNAME 的文件，内容是：

  1	auberginewly.site

  👈 GitHub 通过这个文件知道你的自定义域名。

• 你也可以在域名服务商那边设置一个 CNAME DNS记录（如果你想配置子域名，比如 www.auberginewly.site）

🧩 CNAME 有两种常见用途：

✅ 如何使用？

如果你只想用 auberginewly.site：

• ✅ 你只需要在 GitHub 仓库里加一个[[ ]]CNAME 文件
• ✅ DNS 添加 A 记录，不用设置 CNAME DNS记录

adds

另外，域名配置就到此为止了，想要使用加速服务，租一台服务器并备案反向代理镜像，或者把博客部署在其他国内的代码托管平台，后续再跟进喵。

• re:耗时一节线代课，配置域名（）

基于macos的特性，其在4k分辨率之下的屏幕上没有做hidpi的适配，字体模糊，所以需要一些手段强制开启。

参考资料

https://zhuanlan.zhihu.com/p/187530765
https://blog.csdn.net/ningmoon/article/details/136141656
但是第二篇资料当中
指令在m系列芯片的mac上不适用

1

ioreg -lw0 | grep IODisplayPrefsKey | grep -o '/[^/]\+"$'

如图

但是发现了更简便的开启方法 且不用关闭sip带来风险

那就是github上开源项目betterdisplay

https://github.com/waydabber/BetterDisplay
下载dmg

目前我的版本是v3.3.4
拖拽安装
系统设置里选择1920* 1080

开启高分辨率 即可强制开启hidpi且保证字体的大小正常
不会像默认的2560 1440 那么小了

https://www.anaconda.com

然后配置

修改虚拟环境默认在c盘

修改配置文件路径
“C:\Users\wlyy\.condarc”

修改在文件后加上

这样创建虚拟环境就在指定路径下面

创建虚拟环境并配置需要的包

==已换源==

1
2
3
4
5
6
7
8
9
10
11

conda create --name myenv python=3.10.13 -c https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/

conda activate myenv #激活 myenv可以替换成简单的项目的名字 我用的是ai_test

conda install numpy=1.26.4 -c https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/
conda install pandas=2.2.2 -c https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/
conda install scikit-learn=1.5.1 -c https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/
conda --no-plugins install matplotlib=3.9.2 -c https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/
conda --no-plugins install seaborn=0.13.2 -c https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/
conda --no-plugins install tensorflow=2.10.0 -c https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/
conda --no-plugins install jupyter=1.0.0 -c https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/

退出环境

1

conda deactivate

进入

1

conda activate xxx(虚拟环境名字)

==安装这些包的时候记得一定要进入到虚拟环境当中 不要在base里安装了 这些纯纯无用功==

CondaValueError: You have chosen a non-default solver backend (libmamba) but it was not recognized. Choose one of: classic 报错

解决方式
如果不想使用 libmamba
强制切换默认解析器

1
2
3
4
5
6

# 临时使用 classic（仅当前命令生效）
conda install --solver=classic 你的包名

# 永久切换回 classic
conda config --set solver classic

这样就解决了报错

在pycharm里配置conda环境找不到conda环境 这个离谱问题需要离谱的解决方式

https://blog.csdn.net/m0_73262230/article/details/144005565
参考

settings添加解释器

选择现有的
然后选择conda.bat
再选择创建好的虚拟环境
就可以了

一个报错 导致无法运行出对比的窗口

OMP: Error #15: Initializing libiomp5md.dll, but found libiomp5 already initialized. OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://www.intel.com/software/products/support/.

参考的解决方式
https://blog.csdn.net/peacefairy/article/details/110528012
使用的方法一解决的
在虚拟环境其中找到了俩libiomp5md.dll
做好了路径和备份

然后删除了第二个
运行
恢复正常

可以成功预测 试验成功

这个是之前的报错的

https://blog.csdn.net/theaipower/article/details/145144461
后面的部分可以不用改
因为我改了之后会跳走
打不开typora

• 安装git

1

brew install git

• 配置git

1
2

git config --global user.name "Your Name"
git config --global user.email "email@example.com"

• 因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。你也许会担心，如果有人故意冒充别人怎么办？这个不必担心，首先我们相信大家都是善良无知的群众，其次，真的有冒充的也是有办法可查的。

• 注意git config命令的--global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

创建版本库

• 什么是版本库呢？版本库又名仓库（Repository），你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

1
2
3
4

cd /Users/wly
mkdir learngit
cd learngit
pwd

然后就会显示

1

/Users/wly/learngit

可以看到这个pwd显示当前目录

• git init 可以把这个目录变成Git可以管理的仓库

1
2
3
4
5
6
7
8
9
10

提示： 使用 'master' 作为初始分支的名称。这个默认分支名称可能会更改。要在新仓库中
提示： 配置使用初始分支名，并消除这条警告，请执行：
提示：
提示： git config --global init.defaultBranch <名称>
提示：
提示： 除了 'master' 之外，通常选定的名字有 'main'、'trunk' 和 'development'。
提示： 可以通过以下命令重命名刚创建的分支：
提示：
提示： git branch -m <name>
已初始化空的 Git 仓库于 /Users/wly/learngit/.git/

• 空的仓库（empty Git repository）

• 多了一个.git的目录

  • 这个目录是Git来跟踪管理版本库的
  • ==不要轻易改动w==

• 如果你没有看到.git目录，那是因为这个目录默认是隐藏的，用ls -ah命令就可以看见

• 

• 这样就看到了

把文件添加到版本库

注意喵：

• 首先这里再明确一下，所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。
• 不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，前面我们举的例子只是为了演示，如果要真正使用版本控制系统，就要以纯文本方式编写文件。
• 因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。
• 使用Windows的童鞋要特别注意：千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。建议你下载Visual Studio Code代替记事本，不但功能强大，而且免费！
• 编写一个txt
• vi readme.txt esc退出编辑 :wq! 保存退出
• readme.txt如下：

1
2

Git is a version control system.
Git is free software.

• 一定要放在learngit的目录下面，子目录也行。
• 接下来把这个文件放到git仓库当中去：

添加add

1

git add readme.txt

提交commit

• -m是本次提交的说明，就相当于写了注释，这次提交是为了干什么

1

git commit -m "wrote a readme file"

1
2
3

[master（根提交） 6e8be91] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt

• git commit命令执行成功后会告诉你，1 file changed：1个文件被改动（我们新添加的readme.txt文件）；2 insertions：插入了两行内容（readme.txt有两行内容）。
  另外为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

1
2
3

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

时光机穿梭 git stutus 随时查看工作区状态

修改readme.txt后

1
2
3
4
5
6
7
8

git status
位于分支 master
尚未暂存以备提交的变更：
  （使用 "git add <文件>..." 更新要提交的内容）
  （使用 "git restore <文件>..." 丢弃工作区的改动）
修改：     readme.txt

提交为空，但是存在尚未跟踪的文件（使用 "git add" 建立跟踪）

• git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改。
• 看看具体修改了什么内容git diff xx

1
2
3
4
5
6
7
8
9

git diff readme.txt
diff --git a/readme.txt b/readme.txt
index 46d49bf..9247db6 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
-Git is a version control system.
+Git is a distributed version control system.
 Git is free software.

• 然后git add git status git commit -m "xx" git status可以添加 确认状态 再上传commit

1
2
3

git commit -m "add distributed"
[master 9d6f833] add distributed
 1 file changed, 1 insertion(+), 1 deletion(-)

1
2
3

git status
位于分支 master
无文件要提交，干净的工作区

版本回退

再次修改readme.txt

1
2
3
4

git add readme.txt
git commit -m "append GPL"
[master f1db449] append GPL
 1 file changed, 1 insertion(+), 1 deletion(-)

可以理解下git的commit作为虚拟机的快照
游戏存档之类的
git log查看最近提交的日志

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

git log
commit f1db449a9da173805d7170f023cf5f4f86e895a8 (HEAD -> master)
Author: auberginewly <3127221787@qq.com>
Date:   Mon Apr 14 21:14:39 2025 +0800

    append GPL

commit 17c1986de12e570396e2460494f6060d3bd0b5aa
Author: auberginewly <3127221787@qq.com>
Date:   Mon Apr 14 20:46:03 2025 +0800

    commit

commit 9d6f833c3fbf1865ba68726f2e8efe4dc2ffc594
Author: auberginewly <3127221787@qq.com>
Date:   Mon Apr 14 20:41:16 2025 +0800

    add distributed

commit 6e8be91f1b3351246c8d2fb9b1c4822230b1db56
Author: auberginewly <3127221787@qq.com>
Date:   Mon Apr 14 20:17:35 2025 +0800

    wrote a readme file

• 如果觉得输出的内容太多，可以这么修改--pretty=oneline

1
2
3
4
5

git log --pretty=oneline
f1db449a9da173805d7170f023cf5f4f86e895a8 (HEAD -> master) append GPL
17c1986de12e570396e2460494f6060d3bd0b5aa commit
9d6f833c3fbf1865ba68726f2e8efe4dc2ffc594 add distributed
6e8be91f1b3351246c8d2fb9b1c4822230b1db56 wrote a readme file

• 和SVN不一样，Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示，而且你看到的commit id和我的肯定不一样，以你自己的为准。为什么commit id需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本号，那肯定就冲突了。

把readme.txt版本回退

每提交一个新版本，实际上Git就会把它们自动串成一条时间线。
首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

• 回退git reset

1
2

git reset --hard HEAD^
HEAD 现在位于 17c1986 commit

• 参数
  • --hard参数有啥意义？--hard会回退到上个版本的已提交状态
  • 而--soft会回退到上个版本的未提交状态
  • --mixed会回退到上个版本已添加但未提交的状态
  • 现在，先放心使用--hard。

看readme.txt的内容，回退了。

其实还可以继续回退到之前的版本
但是查看版本库

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

git log
commit 17c1986de12e570396e2460494f6060d3bd0b5aa (HEAD -> master)
Author: auberginewly <3127221787@qq.com>
Date:   Mon Apr 14 20:46:03 2025 +0800

    commit

commit 9d6f833c3fbf1865ba68726f2e8efe4dc2ffc594
Author: auberginewly <3127221787@qq.com>
Date:   Mon Apr 14 20:41:16 2025 +0800

    add distributed

commit 6e8be91f1b3351246c8d2fb9b1c4822230b1db56
Author: auberginewly <3127221787@qq.com>
Date:   Mon Apr 14 20:17:35 2025 +0800

    wrote a readme file

之前的记录已经找不到了捏
办法其实还是有的，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个append GPL的commit id是f1db449a9da173805d7170f023cf5f4f86e895a8，于是就可以指定回到未来的某个版本：

1

git reset --hard f1db4

再看readme.txt的文本

Git在内部有个指向当前版本的HEAD指针

git版本回退速度非常快
当你回退版本的时候，Git仅仅是把HEAD从指向append GPL

然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

• 如果找不到新版本的commit id怎么办
• git reflog用来记录你的每一次命令

1
2
3
4
5
6
7

git reflog
f1db449 (HEAD -> master) HEAD@{0}: reset: moving to f1db4
17c1986 HEAD@{1}: reset: moving to HEAD^
f1db449 (HEAD -> master) HEAD@{2}: commit: append GPL
17c1986 HEAD@{3}: commit: commit
9d6f833 HEAD@{4}: commit: add distributed
6e8be91 HEAD@{5}: commit (initial): wrote a readme file

工作区和暂存区

Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。

工作区（Working Directory）

在电脑里可以看到的目录，learngit文件夹就是一个工作区。

版本库（Repository）

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。
Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

文件添加到版本库

• git add把文件添加进去，添加到暂存区stage
• git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支master
  因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
  ==需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。==

进行一些修改

readme.txt
加一个LICENSE文本文件

1
2
3
4
5
6
7
8
9
10
11
12

git status
位于分支 master
尚未暂存以备提交的变更：
  （使用 "git add <文件>..." 更新要提交的内容）
  （使用 "git restore <文件>..." 丢弃工作区的改动）
修改：     readme.txt

未跟踪的文件:
  （使用 "git add <文件>..." 以包含要提交的内容）
LICENSE.txt

修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）

使用git add把readme.txt和LICENSE都添加到stage

使用git commit把暂存区的东西都提交到分支上

1
2
3

git status
位于分支 master
无文件要提交，干净的工作区

一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的

变成了这样喵

管理修改

Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。
修改readme.txt

1
2
3
4
5

cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes.

add

1
2
3
4
5
6

git add readme.txt
git status
位于分支 master
要提交的变更：
  （使用 "git restore --staged <文件>..." 以取消暂存）
修改：     readme.txt

再次修改readme.txt commit

1
2
3
4

git commit -m "git tracks changes"

[master da65a0b] git tracks changes
 1 file changed, 1 insertion(+)

查看状态

1
2
3
4
5
6
7
8

git status
位于分支 master
尚未暂存以备提交的变更：
  （使用 "git add <文件>..." 更新要提交的内容）
  （使用 "git restore <文件>..." 丢弃工作区的改动）
修改：     readme.txt

修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）

==你看，我们前面讲了，Git管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。==
用git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别

1
2
3
4
5
6
7
8
9
10
11
12

git diff HEAD -- readme.txt
diff --git a/readme.txt b/readme.txt
index 76d770f..9a8b341 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,4 +1,4 @@
 Git is a distributed version control system.
 Git is free software distributed under the GPL.
 Git has a mutable index called stage.
-Git tracks changes.
+Git tracks changes of files.
\ No newline at end of file

第二次修改没提交

撤销修改

git checkout -- file可以撤销工作区的修改，file是文件名

• 一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
• 一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
• 让这个文件回到最近一次git commit或git add时的状态。
  注意：
• git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。
  命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区
  git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。

删除文件

1

rm test.txt

1
2
3
4
5
6
7
8
9
10

git status
位于分支 master
尚未暂存以备提交的变更：
  （使用 "git add/rm <文件>..." 更新要提交的内容）
  （使用 "git restore <文件>..." 丢弃工作区的改动）
修改：     .DS_Store
修改：     readme.txt
删除：     test.txt

修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）

选择1 从版本库当中删除文件

git rm 删掉
git commit 提交

选择2 删错了 但是版本库里还有 可以恢复

1

git checkout -- test.txt

注意

先手动删除文件，然后使用git rm <file>和git add<file>效果是一样的。

远程仓库

Git是分布式版本控制系统，同一个Git仓库，可以分布到不同的机器上。怎么分布呢？最早，肯定只有一台机器有一个原始版本库，此后，别的机器可以“克隆”这个原始版本库，而且每台机器的版本库其实都是一样的，并没有主次之分。

github

由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的，所以，需要一点设置：

• 第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步。如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

1

ssh-keygen -t rsa -C "youremail@example.com"

在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

• 第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面，然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容。
  

注意

为什么GitHub需要SSH Key呢？因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。
当然，GitHub允许你添加多个Key。假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，只要把每台电脑的Key都添加到GitHub，就可以在每台电脑上往GitHub推送了。
最后友情提示，在GitHub上免费托管的Git仓库，任何人都可以看到喔（但只有你自己才能改）。所以，不要把敏感信息放进去。
如果你不想让别人看到Git库，有两个办法，一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。
另一个办法是自己动手，搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。

添加远程库

本地git仓库 远程github也有git仓库 两个仓库进行同步

github创建一个库

在本地的github仓库里执行以下命令

1

git remote add origin git@github.com:auberginewly/learngit.git

让本地库关联远程库
添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

把本地库所有内容推送到远程库上

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

git push -u origin master
枚举对象中: 23, 完成.
对象计数中: 100% (23/23), 完成.
使用 8 个线程进行压缩
压缩对象中: 100% (19/19), 完成.
写入对象中: 100% (23/23), 2.11 KiB | 2.11 MiB/s, 完成.
总共 23（差异 6），复用 0（差异 0），包复用 0（来自  0 个包）
remote: Resolving deltas: 100% (6/6), done.
remote: 
remote: Create a pull request for 'master' on GitHub by visiting:
remote:      https://github.com/auberginewly/learngit/pull/new/master
remote: 
To github.com:auberginewly/learngit.git
 * [new branch]      master -> master
分支 'master' 设置为跟踪 'origin/master'。

把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。

after

从现在起，只要本地作了提交，就可以通过命令：

1

git push origin master

把本地master分支的最新修改推送至GitHub

删除远程库（解除关联）

1

git remote -v

可以查看远程库信息

1

git remote rm origin

删除远程库 实际上是解除了本地库和远程库绑定的联系
但是要删除在github上的远程库的时候 还是需要在github上进行操作

从远程克隆库

1

git clone xxx

Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。
使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。
ssh最快
eg

1
2

git clone https://github.com/auberginewly/learngit.git
git clone git@github.com:auberginewly/learngit.git

分支管理

创建与合并分支

理解分支

每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！
不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

命令

创建并切换到dev分支

1

git checkout -b dev

相当于这两个命令的合并

1
2

git branch dev
git checkout dev

然后可以使用git branch 查看命令

对readme.txt做出一些修改
添加

1

Creating a new branch is quick.

添加并提交

1
2
3
4

git add readme.txt
git commit -m "branch test"
[dev 06d9c0b] branch test
 1 file changed, 2 insertions(+), 1 deletion(-)

到这里对dev的工作就结束了，然后我们切换回master分支

1
2
3
4

git checkout master
M.DS_Store
切换到分支 'master'
您的分支与上游分支 'origin/master' 一致。

然后查看readme.txt

1
2
3
4
5

cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes.

添加的修改没了

因为那个提交是在dev分支上，而master分支此刻的提交点并没有变
我们把dev分支的工作成果合并到master分支上

1
2
3
4
5

git merge dev
更新 5c9937b..06d9c0b
Fast-forward
 readme.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能Fast-forward，还有其他方式的合并。
合并完成后，就可以放心地删除dev分支：

1
2

git branch -d dev
已删除分支 dev（曾为 06d9c0b）。

然后查看分支

1
2

git branch
* master

只剩下master了

为什么要创建多个分支？

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

补充：switch

我们注意到切换分支使用git checkout <branch>，而前面讲过的撤销修改则是git checkout -- <file>，同一个命令，有两种作用，确实有点令人迷惑。

实际上，切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支，创建 并 切换 到新的dev分支，可以使用：

1

git switch -c dev

直接切换到 已有 的master分支，可以使用：

1

git switch master

switch比checkout更好理解

解决冲突

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

准备好新的feature1分支

1
2

git switch -c feature1
Switched to a new branch 'feature1'

先修改readme.txt最后一行为

1

Creating a new branch is quick AND simple.

添加并提交变化

1
2
3
4

git add readme.txt
git commit -m "AND simple"
[feature1 50fc8c9] AND simple
 1 file changed, 1 insertion(+), 1 deletion(-)

切换到master分支

1
2
3
4
5

git switch master
M.DS_Store
切换到分支 'master'
您的分支领先 'origin/master' 共 1 个提交。
  （使用 "git push" 来发布您的本地提交）

Git还会自动提示我们当前master分支比远程的master分支要超前1个提交
在master分支上把readme.txt文件的最后一行改为：

1

Creating a new branch is quick & simple.

提交

1
2
3
4

git add readme.txt 
git commit -m "& simple"
[master 91d9f4f] & simple
 1 file changed, 1 insertion(+), 1 deletion(-)

现在master分支和feature1分支都有了各自的提交

likethis

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，比如：

1
2
3
4

git merge feature1
自动合并 readme.txt
冲突（内容）：合并冲突于 readme.txt
自动合并失败，修正冲突然后提交修正的结果。

Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

git status
位于分支 master
您的分支领先 'origin/master' 共 2 个提交。
  （使用 "git push" 来发布您的本地提交）

您有尚未合并的路径。
  （解决冲突并运行 "git commit"）
  （使用 "git merge --abort" 终止合并）

未合并的路径：
  （使用 "git add <文件>..." 标记解决方案）
双方修改：   readme.txt

尚未暂存以备提交的变更：
  （使用 "git add <文件>..." 更新要提交的内容）
  （使用 "git restore <文件>..." 丢弃工作区的改动）
修改：     .DS_Store

修改尚未加入提交（使用 "git add" 和/或 "git commit -a"）

我们可以直接查看readme.txt的内容：

1
2
3
4
5
6
7
8
9
10

cat readme.txt 
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
<<<<<<< HEAD
Creating a new branch is quick & simple.
=======
Creating a new branch is quick AND simple.
>>>>>>> feature1

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存：

1
2
3
4
5

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
Creating a new branch is quick and simple.

再提交：

1
2
3

git add readme.txt 
git commit -m "conflict fixed"
[master 0ed33be] conflict fixed

现在，master分支和feature1分支变成了下图所示：

用带参数的git log也可以看到分支的合并情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

git log --graph --pretty=oneline --abbrev-commit
*   0ed33be (HEAD -> master) conflict fixed
|\  
| * 50fc8c9 (feature1) AND simple
* | 91d9f4f & simple
|/  
* 06d9c0b branch test
* 5c9937b (origin/master) Remove test.txt
* 5e9d9fd Add test.txt
* da65a0b git tracks changes
* 2fb0cae understand how stage works
* f1db449 append GPL
* 17c1986 commit
* 9d6f833 add distributed
* 6e8be91 wrote a readme file

最后，删除feature1分支：

1
2

git branch -d feature1
已删除分支 feature1（曾为 50fc8c9）。

用git log --graph命令可以看到分支合并图。

关于一个参数的解释

这条命令：

1

git log --graph --pretty=oneline --abbrev-commit

我们可以拆成三部分来解释，每个参数都有它的作用：

1. --graph

• 作用：用 ASCII 字符画出分支和合并的图示，比如：

  1 2 3 4 5

  * commit A |\ | * commit B |/ * commit C

  这个图示能直观地看到分支的结构，比如哪儿合并了、哪儿分支了。

2. --pretty=oneline

• 作用：让每个 commit 显示成一行，只包含：

  • 提交的哈希值（默认是完整的，但配合 --abbrev-commit 就是简写的）
  • 提交信息（commit message）

  显示示例：

  1 2	a1b2c3d 修复登录页面bug 4d5e6f7 添加用户注册功能

3. --abbrev-commit

• 作用：缩短提交哈希值，只显示前几位（一般是前 7 位）
• 比如完整哈希是：

  1	a1b2c3d4e5f67890123456789abcdef12345678

  使用这个参数后只显示：

  1

  a1b2c3d

总结一句话：

这条命令会以「一行一个提交、缩短哈希值、带有分支图」的形式，显示 Git 提交历史，简洁直观，非常适合快速查看分支结构和提交信息。

分支管理策略

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

创建并切换dev分支

1
2

git switch -c dev
切换到一个新分支 'dev'

修改readme.txt并将其提交到一个新的commit上

1
2
3
4

git add readme.txt 
git commit -m "add merge"
[dev 10684e3] add merge
 1 file changed, 1 insertion(+)

切换回master

1
2
3
4
5

git switch master
M.DS_Store
切换到分支 'master'
您的分支领先 'origin/master' 共 4 个提交。
  （使用 "git push" 来发布您的本地提交）

禁用fast forward合并dev分支

1
2
3
4

git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'ort' strategy.
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

请注意--no-ff参数，表示禁用Fast forward，因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
用git log看看分支历史

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

git log --graph --pretty=oneline --abbrev-commit
*   9a4ed3f (HEAD -> master) merge with no-ff
|\  
| * 10684e3 (dev) add merge
|/  
*   0ed33be conflict fixed
|\  
| * 50fc8c9 AND simple
* | 91d9f4f & simple
|/  
* 06d9c0b branch test
* 5c9937b (origin/master) Remove test.txt
* 5e9d9fd Add test.txt
* da65a0b git tracks changes
* 2fb0cae understand how stage works
* f1db449 append GPL
* 17c1986 commit
* 9d6f833 add distributed
* 6e8be91 wrote a readme file

合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

不使用Fast forward模式，merge后就像这样

分支策略应用

在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：

Bug分支

软件开发中会有bug的产生，git当中分支相当的强大，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
如果当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交，但是必须尽快修复bug，这个时候，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

1
2

git stash
保存工作目录和索引状态 WIP on dev: 10684e3 add merge

这个时候查看状态就是干净的

1
2
3

git status
位于分支 dev
无文件要提交，干净的工作区

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

1
2
3
4
5
6

git checkout master 
切换到分支 'master'
您的分支领先 'origin/master' 共 6 个提交。
  （使用 "git push" 来发布您的本地提交）
git checkout -b issue-101
切换到一个新分支 'issue-101'

修改并提交

1
2
3
4

git add readme.txt
git commit -m "fixed text"
[issue-101 ebea9af] fixed text
 1 file changed, 1 insertion(+), 1 deletion(-)

修改完，切换到master分支，并且删除issue-101分支：

1
2
3
4
5
6
7
8