Benjamin's website

一年程序员的认知成长：看问题的三个层次

benjamin — Sat, 09 Aug 2025 04:37:08 GMT

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://benlifec.com/posts/life/cognize

毕业一年后，我越来越发现，职场和生活中的问题，表面上看是一些“突发的小事”，但背后往往有更深层的规律在运作。刚工作那会儿，我总是被眼前的事件浪花吸引，看到裁员新闻就慌，看到市场利好就兴奋，直到后来经历了几轮项目的起落，才慢慢体会到：浪花只是表象，真正决定海面形态的是潮汐，甚至是更深层的气候和地理。

这一认知转变，来自我最近接触到的一个分析框架——“看问题的三个层次”： 事件（浪花） → 局势（潮汐） → 结构（气候/地理/生产关系）。它用自然现象做隐喻，把复杂系统拆解为三个时间和空间维度，让人既能看清当下，又能看见更远。

一、三个层次：从表象到本质

1. 事件（浪花）：短促、孤立、容易被看到

事件是短时间内发生的具体现象，可以用“5W1H”清楚描述。比如：

某互联网公司突然宣布裁员10%
某城市暴雨引发内涝

它们像海面上的浪花，变化快、随机性强、孤立存在——很容易吸引注意，但单看一个浪花，很难判断整个海的走向。

2. 局势（潮汐）：关联、周期、可预测

局势是事件之间的组合与趋势，是时间维度上延展的因果链。

同一行业连续 3 年收缩
全球变暖背景下极端天气频率逐年增加

它像潮汐，不是偶然的浪花，而是方向性的波动。通过局势，我们能提前看到事件的“批量到来”。

3. 结构（气候/地理/生产关系）：稳定、底层、长期约束

结构是最底层的规则——地理、制度、技术——决定了局势可能出现的形态，也限制了事件的发生方式。

地理结构：沿海平原适合农业 → 人口密集 → 经济形态特殊
社会结构：资本逐利性 → 周期性经济危机
技术结构：互联网普及 → 信息传播成本骤降 → 商业格局重塑

它像气候与地理，短期不变，却长期塑造海洋的面貌。

二、事件，局势，结构的相互作用

三个层次并非孤立存在，而是嵌套、动态关联的。

结构决定局势，局势塑造事件 比如：新航路开辟（结构变化）→ 欧洲殖民扩张（局势）→ 英国纺织业爆发（事件）。
事件积累反作用于局势，甚至改变结构 工业革命早期工人罢工（事件）→ 工会制度化（局势）→ 八小时工作制普及（结构调整）。
稳定结构与动态局势的张力 传统燃油车产业链（结构）稳定多年 → 电动车兴起（事件）→ 全球能源转型（局势）→ 汽车产业结构可能被重构。

三、如何训练“三层思维”

1. 观察：用提问清单强制分层

事件：它是孤立还是同类事件的重复？直接原因是什么？
局势：过去几年是否出现过类似趋势？影响范围有多大？
结构：是否有长期不变的基础条件？改变它会怎样？

以“2021年全球芯片短缺”为例：

事件：某车企因缺芯停产
局势：半导体产能不足，多个行业受冲击
结构：ASML 技术垄断、产业链区域分布不均、地缘政治博弈

2. 学习：跨学科积累结构敏感度

地理学看自然结构
经济学、社会学看社会结构
技术史、技术哲学看技术结构

例如分析“城市化”：

事件：地铁开通
局势：人口向沿海城市聚集
结构：土地财政、户籍制度、港口优势

3. 实践：用模拟推演验证

假设结构 → 推演局势 → 用事件验证。比如短视频对传统媒体的冲击：

结构假设：移动互联网普及降低内容门槛
局势预测：广告收入下降、受众流失
事件验证：电视台收视率下滑、报社转型做短视频

四、为什么程序员也该学“三层思维”

作为程序员，我发现这个框架和调试系统很像：

事件：一次 Bug 报错（表象）
局势：同一模块频繁出 Bug（趋势）
结构：架构设计缺陷或业务流程问题（底层）

只盯着报错修 Bug，永远陷在浪花里；看清潮汐，才能做中期优化；触动结构，才可能从根上解决问题。

总结事件、局势、结构，本质是“点-线-网”的三维透视法：

改事件，看短期
改局势，看中期
改结构，看长期

一年职场的体会是： 不要被浪花迷住眼，要学会读潮汐，看懂气候，这样才能在风浪中掌舵，而不是被海浪推着走。

看完了？说点什么呢

[JS] 我所理解的 JavaScript （下）

benjamin — Mon, 24 Mar 2025 08:08:00 GMT

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://benlifec.com/posts/frontend/js_next

接触 Javascript 这门编程语言，满打满算应该有将近 4 年的时间，我觉得不能说对这门语言理解的有多深刻，只是在看了众多的经典书籍和博客之后，想把自己的理解和总结也分享出来。

This

《你不知道的 JavaScript 下》这本书当中关于 this 内容我觉得很好的阐述了 this 的绑定规则。
- 默认绑定: 独立函数调用, 直接调用一个函数, 可以将这条规则看作是无法引用与其他规则的默认规则。(全局函数当中的 this 在非严格模式下等于 window, 在严格模式下等于 undefined)。
- 显示绑定: 通过 apply 和call 来显示绑定this, 还有一种显示绑定的变种是硬绑定 bind()。
- 隐式绑定:比如调用对象的方法那么方法当中的 this 会指向该对象。隐式绑定有 this 丢失问题, 函数别名var bar = obj.foo; bar(); 传入函数参数, 传入语言内置的函数(setTimeout 函数，点击事件)都会导致 this 丢失。
- new 绑定: .绑定构造函数当中的 this 到实例对象.
  - new 一个构造函数发生了什么： 1.创建一个空对象(实例对象)。 2.将实例对象的__proto__指定到构造函数的prototype上。 3.绑定构造函数当中的 this 到实例对象, 执行构造函数当中的代码，给实例对象赋值属性和方法。 4.构造函数当中是否有返回值 ,没有就返回这个实例对象, 有就看返回的是否是对象类型, 是就返回这个对象, 不是就返回实例对象。

this 的四项绑定规则案例

默认绑定

// 默认绑定: 独立函数调用
// 1.案例一:
function foo() {
  console.log(this);
}
foo();

// 2.案例二:
function foo1() {
  console.log(this);
}

function foo2() {
  console.log(this);
  foo1();
}

function foo3() {
  console.log(this);
  foo2();
}

foo3();

// 3.案例三:
function foo() {
  function bar() {
    console.log(this);
  }
  return bar;
}

var fn = foo();
fn(); // window

隐式绑定

// 案例一
var obj = {
  name: 'why',
  foo: function () {
    console.log(this);
  },
};

var bar = obj.foo; // 函数别名 this丢失
bar(); // window
// 案例二
function foo() {
  console.log(this);
}
var obj = {
  name: 'why',
  foo: foo,
};

var bar = obj.foo; // 函数别名 this丢失
bar(); // window
// 案例三
var a = 'global';
function foo(fn) {
  fn();
}
var obj = {
  a: 'local',
  eating() {
    console.log(this.a, '正在吃饭'); // 函数参数 this丢失
  },
};
foo(obj.eating); // global 正在吃饭
// 注意在node环境下调试的时候，全局的this指向空对象
// 案例四
setTimeout(() => {
  console.log(this); // window 传入系统内置的函数
}, 1000);
// 案例五
div.addEventListener('click', function () {
  console.log(this); // Dom div 传入系统内置的函数
});
// 案例6 map filter
arr.map((item) => {
  console.log(this); //默认是window第二个参数可以指定绑定 this 传入系统内置的函数
}, obj);

显示绑定

function foo() {
  console.log('函数被调用了', this);
}
var obj = {
  name: 'obj',
};

// call / apply是可以指定this的绑定对象;
foo.call(obj, 参数);
foo.apply(obj, 参数列表);
foo.apply('aaaa');

new 绑定

function Person(name, age) {
  this.name = name;
  this.age = age;
}

var p1 = new Person('why', 18);
console.log(p1.name, p1.age);

this 绑定的优先级

new 绑定 > 显示绑定 > 隐式绑定 > 默认绑定。

显示绑定优先级高于隐式代码

const obj = {
  name: 'ryan',
  getName() {
    return this.name;
  },
};
console.log(obj.getName.call('string')); // this -> string;
//更明显的比较
function foo() {
  console.log(this);
}

var obj = {
  foo: foo.bind('aaa'),
};
obj.foo(); // this -> 'aaa';

new 绑定大于隐式绑定代码

var obj = {
  name: 'ryan',
  getName() {
    return this.name;
  },
};
let fn = new obj.getName(); this -> 实例对象fn

new 绑定大于显示绑定代码

// 由于new 和 call以及apply都是调用函数，自然就不可以一起使用。
function foo() {
  console.log(this);
}
const fn = foo.bind('a');
const nFn = new fn();
console.log(nFn); this -> 实例对象nFn

特殊绑定

忽略显示绑定

// apply/call/bind: 当传入 null/undefined 时, 自动将 this 绑定成全局对象
foo.apply(null);
foo.apply(undefined);

规范绑定

var obj1 = {
  name: 'obj1',
  foo: function () {
    console.log(this);
  },
};

var obj2 = {
  name: 'obj2',
};
(obj2.bar = obj1.foo)();

箭头函数当中的 this

箭头函数不绑定 this，没有 arguments，也不可以作为构造函数使用 new 来调用。
箭头函数当中的 this 指向外层全局或者函数作用域当中的 this。

var obj = {
  data: [],
  getData: function () {
    setTimeout(() => {
      var result = ['abc', 'cba', 'nba'];
      this.data = result;
    }, 2000);
  },
};

this 面试题

面试题误区

var obj = {
  name: 'ryan',
  getName: () => {
    return this.name;
  },
};

// ""

如果真的弄懂了以上规则，刷题如切菜般容易。
getName 的外层作用域是全局作用域，而不是 obj 对象大括号作用域。因为在 js 当中只有全局作用域和函数作用域。
给箭头函数绑定 this 是徒劳的((() => {}).call('string'))。

面试题 1

var name = 'window';

var person = {
  name: 'person',
  sayName: function () {
    console.log(this.name);
  },
};

function sayName() {
  var sss = person.sayName;
  sss(); // window: 独立函数调用
  person.sayName(); // person: 隐式调用
  `(person.sayName())`; // person: 隐式调用
  (b = person.sayName)(); // window: 赋值表达式(独立函数调用)

sayName();

面试题 2

var name = 'window';

var person1 = {
  name: 'person1',
  foo1: function () {
    console.log(this.name);
  },
  foo2: () => console.log(this.name),
  foo3: function () {
    return function () {
      console.log(this.name);
    };
  },
  foo4: function () {
    return () => {
      console.log(this.name);
    };
  },
};

var person2 = { name: 'person2' };

person1.foo1(); // person1(隐式绑定)
person1.foo1.call(person2); // person2(显示绑定优先级大于隐式绑定)

person1.foo2(); // window(不绑定作用域,上层作用域是全局)
person1.foo2.call(person2); // window

person1.foo3()(); // window(独立函数调用)
person1.foo3.call(person2)(); // window(独立函数调用)
person1.foo3().call(person2); // person2(最终调用返回函数式, 使用的是显示绑定)

person1.foo4()(); // person1(箭头函数不绑定this, 上层作用域this是person1)
person1.foo4.call(person2)(); // person2(上层作用域被显示的绑定了一个person2)
person1.foo4().call(person2); // person1(上层找到person1)

面试题三

var name = 'window';

function Person(name) {
  this.name = name;
  (this.foo1 = function () {
    console.log(this.name);
  }),
    (this.foo2 = () => console.log(this.name)),
    (this.foo3 = function () {
      return function () {
        console.log(this.name);
      };
    }),
    (this.foo4 = function () {
      return () => {
        console.log(this.name);
      };
    });
}

var person1 = new Person('person1');
var person2 = new Person('person2');

person1.foo1(); // person1
person1.foo1.call(person2); // person2(显示高于隐式绑定)

person1.foo2(); // person1 (上层作用域中的 this 是 person1)
person1.foo2.call(person2); // person1 (上层作用域中的 this 是 person1)

person1.foo3()(); // window(独立函数调用)
person1.foo3.call(person2)(); // window
person1.foo3().call(person2); // person2

person1.foo4()(); // person1
person1.foo4.call(person2)(); // person2
person1.foo4().call(person2); // person1

var obj = {
  name: 'obj',
  foo: function () {},
};

面试题四

var name = 'window';

function Person(name) {
  this.name = name;
  this.obj = {
    name: 'obj',
    foo1: function () {
      return function () {
        console.log(this.name);
      };
    },
    foo2: function () {
      return () => {
        console.log(this.name);
      };
    },
  };
}

var person1 = new Person('person1');
var person2 = new Person('person2');

person1.obj.foo1()(); // window 独立函数调用
person1.obj.foo1.call(person2)(); // window
person1.obj.foo1().call(person2); // person2

person1.obj.foo2()(); // obj
person1.obj.foo2.call(person2)(); // person2
person1.obj.foo2().call(person2); // obj

异步

异步概述

异步是计算机科学的一个基本概念，其中一种含义是计算机多线程的异步处理，也可以说异步行为就是在等待其他操作完成的同时，也可以运行其他指令，这样可以优化计算量大，时间长的操作。Java/go 语言当中可以通过线程池 runtime /goroutine 来实现异步，但是对于我们 JavaScript 这种单线程语言（一次只能完成一个任务）。我们是通过 JavaScript 的事件循环模型，结合浏览器多线程管理回调函数作为异步解决方案。也就是将 DOM操作，HTTP 请求，定时器等的回调函数都交给浏览器的对应线程来管理，有了操作结果之后就将回调函数加入 JavaScript 事件循环模型的消息队列当中，当 JavaScript主线程空闲时，就会轮询消息队列，将异步任务读取到调用栈当中等待主线程的顺序执行。

异步解决方案

在早期 JavaScript 中，只支持回调函数来处理异步操作返回的结果。之后出现的 Promise 和 Async 其实本质上仍然是在处理和表达回调函数。只不过从我们作为开发者的角度来说，我们可以用一些优雅的，安全的，可以信任的语法来换一种形式来处理异步回调函数。

早期回调函数

早期回调函数处理异步回调的缺陷十分明显：

第一个是线性理解能力的缺失，我们期望的异步方式是有计划的，线性的。比如：我通过 HTTP 请求，获取数据之后在操作数据，但是回调在表达异步的时候是非顺序的，非线性的。比如：我先定义好拿到数据之后的操作，再去 HTTP 请求。
第二个是嵌套回调异步，如果异步返回值又依赖另一个异步返回值，回调的情况还会进一步复杂，最致命的是如果试图向其中添加新特性，他就立马会变得很难以拓展。
第三个是信任缺失，因为没有一种统一的。我们交给第三方库的回调函数，控制权在第三方库手里。所以我们需要一种更好的方案来优雅的处理异步回调函数。

Promise 处理异步回调

通过手写Promise源码过后，我发现Promise在处理异步回调的核心是每次resovle的时候，resovle会挂起一个异步回调任务，然后then同步传递的回调函数放到这个异步任务当中去，之后这个异步回调任务调用then函数。如果是链式调用then之后又继续resovle

之后从三个方面简单介绍一下 Promise。Promise 特性，Promise 静态方法，Promise 实例方法，Promise 缺陷，Promise解决了什么样的问题。

Promise 是一个有三种状态的对象，pending（待定）, fufilled（兑现）, rejected（拒绝）。无论落定为哪种状态都是不可逆的。Promise 的状态转换为兑现，就会有一个兑现的值 value，转换为拒绝，就会有拒绝的原因 reason。
Promise 静态方法 :Promise.resove(), Promise.reject(), Promise.all(), Promise.race(),Promise.allSettled(), Promise.any()。
Promise 实例方法 : Promise.prototype.then(), Promise.prototype.catch(), Promise.prototype.finally()。

Promise 嵌套

// bad
loadSomething().then(function(something) {
    loadAnotherthing().then(function(another) {
        DoSomethingOnThem(something, another);
    });
});

复制代码
// good
Promise.all([loadSomething(), loadAnotherthing()])
.then(function ([something, another]) {
    DoSomethingOnThem(...[something, another]);
});

2.断开的 Promise 链

// bad
function anAsyncCall() {
    var promise = doSomethingAsync();
    promise.then(function() {
        somethingComplicated();
    });

    return promise;
}

// good
function anAsyncCall() {
    var promise = doSomethingAsync();
    return promise.then(function() {
        somethingComplicated()
    });
}

3.混乱的集合

// bad
function workMyCollection(arr) {
    var resultArr = [];
    function _recursive(idx) {
        if (idx >= resultArr.length) return resultArr;

        return doSomethingAsync(arr[idx]).then(function(res) {
            resultArr.push(res);
            return _recursive(idx + 1);
        });
    }

    return _recursive(0);
}

你可以写成：

function workMyCollection(arr) {
    return Promise.all(arr.map(function(item) {
        return doSomethingAsync(item);
    }));
}

Promise 解决了什么样的问题

回调嵌套

request(url, function(err, res, body) {
    if (err) handleError(err);
    fs.writeFile('1.txt', body, function(err) {
        request(url2, function(err, res, body) {
            if (err) handleError(err)
        })
    })
});

使用 Promise 后：

request(url)
.then(function(result) {
    return writeFileAsynv('1.txt', result)
})
.then(function(result) {
    return request(url2)
})
.catch(function(e){
    handleError(e)
});

控制反转再反转

使用第三方回调API 的时候，可能会遇到如下问题：

回调函数执行多次 --这个Promise每次只可以resovle一次，剩下的调用会被忽略。

Promise 缺陷

无法中途取消
无法得知 pending 状态，不知道目前进展到哪一个方面
单一值（每次只能有一个完成值或者拒绝原因，我们只能构造对象和数组去解构）
吃掉错误，这块项目当中会很常见：一般会和async await 以及try catch相互配合

如果我们在catch块捕获到了错误，如果你只是做了简单的返回,或者打印，最上层的try catch块是捕获不到的，只有throw抛出错误或者return Promise.reject()才可以被外面的try catch同步捕获到来进行处理。而try catch块同样有这样的局限，也会在 catch 块中吃掉错误，如果想要被上层处理，还得继续抛出。我在项目当中的实践就是如果try catch太多，太冗余，我会使用catch返回错误，去用if判断，可以大大减少冗余。

async，await 处理异步回调

async函数就是Generator函数 + Promise的语法糖，为什么这么说呢？因为我们发现async函数的本质，就是将Generator函数和 co | thunk 执行器包装再了一个async函数里。

Generator 处理异步回调

function* getData(url) {
  const re1 = yield requestData(url);
  const re2 = yield requestData(res1 + url);
  const re3 = yield requestData(res2 + url);
}

手动执行

getData("user_1")
  .next("name")
  .value.then((res) => {
    getData(res)
      .next("id")
      .value.then((res) => {
        getData(res)
          .next()
          .value.then((res) => {
            console.log(res);
          });
      });
  });

co 模块自动执行器

function generator(generatorFun) {
  const generator = generatorFun();
  function execu(res) {
    const generatorObj = generator.next(res);
    if (!generatorObj.done) {
      generatorObj.value.then((res) => {
        execu(res);
      });
    } else {
      return generatorObj.value;
    }
  }
  execu(res);
}

我们用Generator实现异步回调处理的时候，通过生成器函数，yield请求函数a,请求函数b,请求函数c来表达异步处理，通过手动调用.next.then再继续嵌套调用.next.then来执行，之后有了co或者thunk执行器模块，可以帮我们去自动执行，回过头来再看async的写法，发现async函数的本质，就是将Generator函数和执行器包装再了一个async函数里。

async await 处理异步

// async await
async function getData(url) {
  const re1 = await requestData(url);
  const re2 = await requestData(res1 + url);
  const re3 = await requestData(res2 + url);
}

`async` 比 `Promise`的优势？

代码更加简洁。--这个显而易见，我们不用每次把一大把逻辑都放在then处理函数当中。
错误处理。 --由于try catch只能捕获同步错误，所以不能或者说难以捕获Promise 异步回调的错误，async/await的出现使得try/catch 就可以同步捕获异步错误。
调试。 --- 对于await 我们可以按照顺序调试，而Promise并不会顺序执行。

async 陷阱

指开发者贪图语法上的简洁而让原本可以并行执行的内容变成了顺序执行，从而影响了性能

(async () => {
  const getList = await getList();
  const getAnotherList = await getAnotherList();
})();

getList()和getAnotherList() 其实并没有依赖关系，但是现在的这种写法，虽然简洁，却导致了 getAnotherList() 只能在 getList() 返回后才会执行，从而导致了多一倍的请求时间。

(async () => {
  const listPromise = getList();
  const anotherListPromise = getAnotherList();
  await listPromise;
  await anotherListPromise;
})();

也可以使用 Promise.all()：

(async () => {
  Promise.all([getList(), getAnotherList()]).then(...);
})();

async 继发和并发

// 继发一
async function loadData() {
  var res1 = await fetch(url1);
  var res2 = await fetch(url2);
  var res3 = await fetch(url3);
  return "whew all done";
}

// 继发二
async function loadData(urls) {
  for (const url of urls) {
    const response = await fetch(url);
    console.log(await response.text());
  }
}

// 并发一
async function loadData() {
  var res = await Promise.all([fetch(url1), fetch(url2), fetch(url3)]);
  return "whew all done";
}

// 并发二（for循环里面加计时器的案例）
async function loadData(urls) {
  // 并发读取 url
  const textPromises = urls.map(async url => {
    const response = await fetch(url);
    return response.text();
  });

  // 按次序输出
  for (const textPromise of textPromises) {
    console.log(await textPromise);
  }
}

async 错误捕获

// to.js
export default function to(promise) {
   return promise.then(data => {
      return [null, data];
   })
   .catch(err => [err]);
}

import to from './to.js';

async function asyncTask() {
     let err, user, savedTask;
     [err, user] = await to(UserModel.findById(1));
     if(!user) throw new CustomerError('No user found');

     [err, savedTask] = await to(TaskModel({userId: user.id, name: 'Demo Task'}));
     if(err) throw new CustomError('Error occurred while saving task');

    if(user.notificationsEnabled) {
       const [err] = await to(NotificationService.sendNotification(user.id, 'Task Created'));
       if (err) console.error('Just log the error and continue flow');
    }
}

async 的一些讨论

async 会取代 Generator 吗？

Generator 本来是用作生成器，使用 Generator 处理异步请求只是一个比较 hack 的用法，在异步方面，async 可以取代 Generator，但是 async 和 Generator 两个语法本身是用来解决不同的问题的。

async 会取代 Promise 吗？

async 函数的就是返回一个 Promise 对象。他们两个相互成就，我觉得可以这样说。
面对复杂的异步流程，Promise 提供的all和 race 会更加好用。会避免掉进await的陷阱里
Promise 本身是一个对象，所以可以在代码中任意传递，缓存。

co 模块自动执行器

co 模块 函数通过回调函数 / Promise对象来接收和交还程序的执行权。从而自动化执行生成器函数。co 模块交还和接收执行权的本质就是等待异步操作的协程有了结果之后，去递归调用传入的回调函数来归还异步函数协程的执行权。

手写 co 函数

const fs = require("fs");

const readFileFn = (filename) => {
  /* Promise交还执行权 */
  return new Promise((resolve, reject) => {
    fs.readFile(filename, (err, data) => {
      if (err) reject(err);
      resolve(data);
    });
  });

  /* 回调函数交还执行权 */
  return (cb) => {
    fs.readFile(filename, (err, data) => {
      if (err) throw err;
      setTimeout(() => {
        cb(data);
      });
    });
  };
};

function* generatorFn() {
  const r1 = yield readFileFn("./a.txt");
  const r2 = yield readFileFn("./b.txt");
  console.log(r1.toString(), r2.toString(), "两个文件读取完毕！！！");
}
const co = (geFn) => {
  const gen = geFn();
  const coRe = (data) => {
    const result = gen.next(data);
    if (result.done) return result.value;
    if (result.value instanceof Promise) {
      result.value.then(coRe);
    } else {
      result.value(coRe);
    }
  };
  coRe();
};
co(generatorFn);

// 第二版
function run(gen) {
    var gen = gen();

    return new Promise(function(resolve, reject) {

        function next(data) {
            try {
                var result = gen.next(data);
            } catch (e) {
                return reject(e);
            }

            if (result.done) {
                return resolve(result.value)
            };
            //统一回调函数和Promise
            var value = toPromise(result.value);

            value.then(function(data) {
                next(data);
            }, function(e) {
                reject(e)
            });
        }

        next()
    })

}

function isPromise(obj) {
    return 'function' == typeof obj.then;
}

function toPromise(obj) {
    if (isPromise(obj)) return obj;
    if ('function' == typeof obj) return thunkToPromise(obj);
    return obj;
}

function thunkToPromise(fn) {
    return new Promise(function(resolve, reject) {
        fn(function(err, res) {
            if (err) return reject(err);
            resolve(res);
        });
    });
}

module.exports = run;

协程概念

协程的概念是多个线程互相协作，完成异步任务。

协程（Coroutines）是一种比线程更加轻量级的存在 , 协程是一个特殊的函数，这个函数可以暂停，保留状态后暂时推出，之后可以重新在暂停处恢复运行。

第一步，协程 A 开始执行。第二步，协程 A 执行到一半，进入暂停，执行权转移到协程 B。第三步，（一段时间后）协程 B 交还执行权。第四步，协程 A 恢复执行。在 ES6 当中可以通过生成器函数可以交出函数的执行权的特性来实现协程。

生成器

生成器是 ES6 的一种对函数执行进行控制的方案。它让我们更加灵活的控制函数什么时候继续执行，什么时候暂停执行。

生成器函数

生成器函数通过 yield 关键字来控制函数执行流程。
生成器函数返回生成器。
yield 之后的返回值是，next方法返回对象的 value 和 done 属性。
- {value: , done: false}
para2 为第二段函数代码的参数。para3 为第三段函数代码的参数。

function* bar() {
  const val_1 = 1;
  console.log("第一段代码执行", val_1);
  const para2 = yield "第一段代码的返回值";
  const val_2 = 2;
  console.log("第二段代码执行", val_2 * value_2);
  const para3 = yield "第二段代码的返回值";
  const val_3 = 3;
  console.log("第三段代码执行", val_3 * value_3);
  yield "第三段代码的返回值";
  console.log("函数执行结束");
}
const generator = bar();
console.log(generator.next());
console.log(generator.next(10));
console.log(generator.next(10));
console.log(generator.next(10));
console.log(generator.next(10));
console.log(generator.next(10));
// 第一段代码执行 1
// { value: '第一段代码的返回值', done: false }
// 第二段代码执行 20
// { value: '第二段代码的返回值', done: false }
// 第三段代码执行 30
// { value: '第三段代码的返回值', done: false }
// 函数执行结束
// { value: undefined, done: true }
// { value: undefined, done: true }
// { value: undefined, done: true }

生成器提前结束 - return 函数

return 传值后这个生成器函数就会结束，之后调用 next 不会继续生成值了；

function* bar() {
  const val_1 = 1;
  console.log("第一段代码执行", val_1);
  const value_2 = yield "第一段代码的返回值";
  const val_2 = 2;
  console.log("第二段代码执行", val_2 * value_2);
  const value_3 = yield "第二段代码的返回值";
  const val_3 = 3;
  console.log("第三段代码执行", val_3 * value_3);
  yield "第三段代码的返回值";
  console.log("函数执行结束");
}
const generator = bar();
console.log(generator.next());
console.log(generator.return(10));
console.log(generator.next(10));
// 第一段代码执行 1
// { value: '第一段代码的返回值', done: false }
// { value: 10, done: true }
// { value: undefined, done: true }

生成器抛出异常 - throw 函数

给生成器函数内部抛出异常

function* bar() {
  const val_1 = 1;
  console.log("第一段代码执行", val_1);
  const value_2 = yield "第一段代码的返回值";
  const val_2 = 2;
  console.log("第二段代码执行", val_2 * value_2);
  const value_3 = yield "第二段代码的返回值";
  const val_3 = 3;
  console.log("第三段代码执行", val_3 * value_3);
  yield "第三段代码的返回值";
  console.log("函数执行结束");
}
const generator = bar();
console.log(generator.next());
console.log(generator.throw("err message"));
console.log(generator.next(10));
//   const value_2 = yield "第一段代码的返回值";
//                   ^
// err message
// (Use `node --trace-uncaught ...` to show where the exception was thrown)

抛出异常后我们可以在生成器函数中捕获异常

function* bar() {
  const val_1 = 1;
  console.log("第一段代码执行", val_1);
  try {
    const value_2 = yield "第一段代码的返回值";
  } catch (err) {
    console.log("捕获了异常" + err);
  }
  const val_2 = 2;
  console.log("第二段代码执行", val_2);
  const value_3 = yield "第二段代码的返回值";
  const val_3 = 3;
  console.log("第三段代码执行", val_3 * value_3);
  yield "第三段代码的返回值";
  console.log("函数执行结束");
}
const generator = bar();
console.log(generator.next());
console.log(generator.throw("err message"));
console.log(generator.next(10));
// 第一段代码执行 1
// { value: '第一段代码的返回值', done: false }
// 捕获了异常err message
// 第二段代码执行 2
// { value: '第二段代码的返回值', done: false }
// 第三段代码执行 30
// { value: '第三段代码的返回值', done: false }

生成器代替迭代器

// 生成器
function* createGenerator(arr) {
  for (const item of arr) {
    yield item;
  }
}
const generator = createGenerator([1, 3]);

// 迭代器
function createIteratot(arr) {
  let index = 0;
  return {
    next: function () {
      if (index < arr.length) {
        return { value: arr[index++], done: false };
      } else {
        return { value: undefined, done: true };
      }
    },
  };
}

生成器原理

**function* helloWorldGenerator() {
  yield 'hello';
  yield 'world';
  return 'ending';
}**

babel 当中有一个非常复杂的原型解构，实现了 next, return, throw 方法。

babel 当中的核心逻辑是，是有一个 while 无限循环，无限循环中有 switch case 语句，分为对应着 0 → hello，1 → world ， 2 → ending 3 → .stop() 每一次 yield 都会匹配 switch 语句，然后去改变 next, pre 属性的值，执行下一个 yield 匹配，最后一个 yield 匹配后最后一个状态会变为 complete , 会 return {value: undefined, done: true}

async 和 await 被 babel 编译后的结果就是，通过 generator + co 自动化的递归的执行 _asyncToGenerator函数。来实现 async/await

let | const | var

块级作用域：块作用域由 { }包括，let 和 const 是块级作用域的块级声明，var 不存在块级作用域。存在变量提升的问题。

变量提升：var 存在变量提升，let 和 const 不存在变量提升。var 的变量提升就是在初始化全局上下文对象的 VO 变量的时候，收集全局函数和全局变量。

暂时性死区：在使用 let、const 命令声明变量之前，该变量都是不可用的。这在语法上，称为暂时性死区。使用 var 声明的变量不存在暂时性死区。

全局作用域：var 声明的变量为全局变量，并且会将该变量添加为全局对象的属性（浏览器环境下是 window,node 环境是 global），但是 let 和 const 不会，他们被添加到一个特殊的变量环境当中来记录。

重复声明：var 声明变量时，可以重复声明变量，后声明的同名变量会覆盖之前声明的变量，const 和 let 不允许重复声明变量。

Set WeakSet | Map Weakmap

Set 和 WeakSet 都是集合数据结构。结构中的每个元素都是唯一的。
通过 add 增加值，has 查询，size 取得元素数量，delete 和 clear 删除元素。
WeakSet 只能使用对象作为值，不接受其他类型的值。

// set 数据结构的基本使用
const set = new Set();
set.add(10); // 返回set对象
set.add(10);
set.add({ name: 'ryan' });
console.log(set);
set.has(10); // 返回布尔值
set.delete(10); // 返回布尔值
console.log(set);
set.clear();
console.log(set);
console.log(set.size);
const set1 = new Set([1, 1, 3, 3, 0]); // 传入可迭代对象

// set的遍历
set.forEach((item) => {
  console.log(item);
});
for (const val of set) {
  console.log(val);
}

const set2 = new WeakSet();
// 注意这样添加的是不同对象。相同的对象 -> const obj = {name: 'ryan'} set.add(obj)
set.add({ name: 'ryan' }); // 返回set对象
set.add({ name: 'ryan' });
set.add({ name: 'ryan' });
console.log(set2);
set.has({ name: 'ryan' }); // 返回布尔值
set.delete({ name: 'ryan' }); // 返回布尔值
// console.log(set2);
// set.clear();
console.log(set2);
console.log(set.size);
const set3 = new WeakSet([{ name: 'ryan' }]); // 传入可迭代对象
console.log(set3);
// set -> []
const arr = Array.from(set2);
const arr2 = [...set2];

Map 和 WeakMap 都是 K V 表，映射数据结果。
之前存储键值对，只能通过 Object，并且有个局限就是属性名只能是字符串类型 ,Symbol 数字类型。Map 的属性可以是任何 JS 类型。
通过 set 添加属性，通过 has 查询，get 获取属性，通过 delete, clear 删除属性。
WeakMap 只能使用对象作为键，不接受其他类型的值。
WeakMap 不可以遍历。也正是因为弱引用这样的特性，WeakMap 内部有多少个成员，取决于垃圾回收机制有没有运行，运行前后很可能成员个数是不一样的，而垃圾回收机制何时运行是不可预测的，因此 ES6 规定 WeakMap 不可遍历。

const map = new Map();
const obj1 = { name: 'why' };
const obj2 = { name: 'kobe' };
map.set(obj1, 'aaa');
map.set(obj2, 'bbb');
map.set(1, 'ccc');

map2.set('why', 'eee');
console.log(map2);
console.log(map2.get('why'));
console.log(map2.has('why'));

map2.delete('why');
console.log(map2);

map2.clear();
console.log(map2);
// 传入entry
const map2 = new Map([
  [obj1, 'aaa'],
  [obj2, 'bbb'],
  [2, 'ddd'],
]);

Dom | Bom

Bom

BOM(Browser Object Model) 浏览器对象模型看成是连接JavaScript 脚本与浏览器窗口的桥梁。

BOM 主要包括一下的对象模型：
- window：包括全局属性、方法。
- location：操作和访问 URL 信息的对象。
- history：操作浏览器的会话历史记录的对象 📝。
- document：操作文档对象。

window

window 作为全局对象

window.setTimeout(() => {
  console.log("setTimeout");
}, 2000);

const obj = new window.Date();

window 常见的属性，方法和事件

// 1.常见的属性
console.log(window.screenX);
console.log(window.screenY);

window.addEventListener("scroll", () => {
  console.log(window.scrollX, window.scrollY);
});

console.log(window.outerHeight);
console.log(window.innerHeight);

// 2.常见的方法
const scrollBtn = document.querySelector("#scroll");
scrollBtn.onclick = function () {
  // 1.scrollTo
  window.scrollTo({ top: 2000 });

  // 2.close
  window.close();

  // 3.open
  window.open("http://www.baidu.com", "_self");
};

// 3.常见的事件
window.onload = function () {
  console.log("window窗口加载完毕~");
};

window.onfocus = function () {
  console.log("window窗口获取焦点~");
};

window.onblur = function () {
  console.log("window窗口失去焦点~");
};

const hashChangeBtn = document.querySelector("#hashchange");
hashChangeBtn.onclick = function () {
  location.hash = "aaaa";
};
window.onhashchange = function () {
  console.log("has发生了h改变");
};

window 继承自 EventTarget

const clickHandler = () => {
  console.log("window发生了点击");
};

window.addEventListener("click", clickHandler);
window.removeEventListener("click", clickHandler);

window.addEventListener("a", () => {
  console.log("a");
});
// 派发事件
window.dispatchEvent(new Event("a"));

location

Location 对象用于表示 window 上当前链接到的 URL 信息。

location 方法

Location.assign() 方法会触发窗口加载并显示指定的 URL 的内容。
Location.replace() 方法以给定的 URL 来替换当前的资源。与 assign()方法不同的是，调用 replace() 方法后，当前页面不会保存到会话历史中（session History），这样，用户点击回退按钮时，将不会再跳转到该页面。
Location.reload() 方法用来刷新当前页面。该方法只有一个参数，当值为 true 时，将强制浏览器从服务器加载页面资源，当值为 false 或者未传参时，浏览器则可能从缓存中读取页面。

location 属性

打开https://developer.mozilla.org/zh-CN/docs/Web/API
console.log(location)
hash: ""
host: "developer.mozilla.org"
hostname: "developer.mozilla.org"
href: "https://developer.mozilla.org/zh-CN/docs/Web/API"
origin: "https://developer.mozilla.org"
pathname: "/zh-CN/docs/Web/API"
port: ""
protocol: "https:"

history

history 对象允许我们访问浏览器曾经的会话历史记录。

history 属性

length：会话中的记录条数。
state：当前保留的状态值。

history 方法

back()返回上一页，等价于 history.go(-1)。
forward()前进下一页，等价于 history.go(1)。
go()加载历史中的某一页。
pushState()；只是改变跳转路径不刷新网页。
replaceState()打开一个新的地址，并且使用 replace没有会话记录。

Dom

Node接口继承了 EventTarget，而像 Document,Element 都继承自 Node 接口。
继承自 EventTarget 可以使用 addEventListener, removeEventListener, dispatchEvent。
继承 Node 可以使用 nodeValue, nodeType, childNodes
element → classLIst className style, clientHeight, clientHeight
document → document.titile document.body, document.querySelector()

继承自 EventTarget

addEventListener, removeEventListener, dispatchEvent。

// document
document.addEventListener("click", () => {
  console.log("document被点击");
});

const divEl = document.querySelector("#box");
const spanEl = document.querySelector(".content");
// element -> HTMLElement
divEl.addEventListener("click", () => {
  console.log("div元素被点击");
});

spanEl.addEventListener("click", () => {
  console.log("span元素被点击");
});

继承 Node

const divEl = document.querySelector("#box");
const spanEl = document.querySelector(".content");

// 常见的属性
console.log(divEl.nodeName, spanEl.nodeName);
console.log(divEl.nodeType, spanEl.nodeType);
console.log(divEl.nodeValue, spanEl.nodeValue);

// childNodes
const spanChildNodes = spanEl.childNodes;
const textNode = spanChildNodes[0];
console.log(textNode.nodeValue);

// 常见的方法
const strongEl = document.createElement("strong");
strongEl.textContent = "我是strong元素";
divEl.appendChild(strongEl);
document.body.appendChild(strongEl);

Document

// 常见的属性
console.log(document.body);
console.log(document.title);
document.title = "Hello World";

console.log(document.head);
console.log(document.children[0]);

console.log(window.location);
console.log(document.location);
console.log(window.location === document.location);
// true
const imageEl = document.createElement("img");
const imageEl2 = new HTMLImageElement();

// 获取元素
const divEl1 = document.getElementById("box");
const divEl2 = document.getElementsByTagName("div");
const divEl3 = document.getElementsByName("title");
const divEl4 = document.querySelector(".content");
const divEl5 = document.querySelectorAll(".content");

Element

const divEl = document.querySelector("#box");

// 常见的属性
console.log(divEl.id);
console.log(divEl.tagName);
console.log(divEl.children);
console.log(divEl.className);
console.log(divEl.classList);
console.log(divEl.clientWidth);
console.log(divEl.clientHeight);
console.log(divEl.offsetLeft);
console.log(divEl.offsetTop);

// 常见的方法
const value = divEl.getAttribute("age");
console.log(value);
divEl.setAttribute("height", 1.88);

事件监听（事件流）

事件流包含三个阶段:

事件捕获阶段
目标阶段
事件冒泡阶段

首先发生的是事件捕获，沿着 DOM 树一路向下，在经过的每个 dom 节点依次触发监听的事件。直到目标 dom 节点 document -> html -> body -> div。

然后是实际的目标 dom 节点接收到事件，触发目标节点绑定事件/触发代理事件

最后阶段是事件冒泡阶段，沿着 DOM 树一路向上，在经过的每个 dom 节点依次触发监听的事件。直到 document 对象 div -> body -> html -> document。

事件冒泡

沿着 DOM 树一路向上，在经过的每个节点依次触发。直到 document 对象 div -> body -> html -> document。

spanEl.addEventListener("click", () => {
  console.log("事件冒泡:span元素被点击了");
});

divEl.addEventListener("click", () => {
  console.log("事件冒泡:div元素被点击了");
});

document.body.addEventListener("click", () => {
  console.log("事件冒泡:body元素被点击了");
});

document.addEventListener("click", () => {
  console.log("事件冒泡:document元素被点击了");
});

事件捕获

沿着 DOM 树一路向下，在经过的每个节点依次触发。直到目标对象 document -> html -> body -> div。

spanEl.addEventListener(
  "click",
  (event) => {
    console.log("事件捕获:span元素被点击了");
    event.stopPropagation();
  },
  true
);

divEl.addEventListener(
  "click",
  () => {
    console.log("事件捕获:div元素被点击了");
  },
  true
);

document.body.addEventListener(
  "click",
  (event) => {
    console.log("事件捕获:body元素被点击了");
  },
  true
);

事件代理

事件代理又称之为事件委托，事件代理是把原本需要绑定在子元素的事件委托给父元素，让父元素负责事件监听和处理。

事件代理的好处是有两点：

第一点：可以大量节省内存占用，减少事件注册事件。

第二点：当新增子对象时无需再次对其绑定

为什么父元素能做到事件代理呢？笔者认为有两点：

第一点 ：事件冒泡到父元素，父元素可以订阅到冒泡事件。

第二点：可以通过 event.target 得到目标节点。不然, 父元素怎么针对不同的子节点，进行定制化事件代理。

事件对象的属性和方法

eventTarget 和·currentTarget 的区别：
- 点击父元素中的子元素。
- eventTarget | target 指向子元素，currentTarget 指向父元素。
事件委托，向父元素上监听事件来操作子元素。

divEl.addEventListener('click', (event) => {
  console.log('span元素被点击:', event);
  console.log('事件的类型:', event.type);
  console.log('事件的元素:', event.target, event.currentTarget);
  console.log('事件发生的位置:', event.offsetX, event.offsetY);
});

看完了？说点什么呢

[JS] 我所理解的 JavaScript （上）

benjamin — Mon, 24 Mar 2025 02:10:45 GMT

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://benlifec.com/posts/frontend/js_pre

接触 Javascript 这门编程语言，满打满算应该有将近 4 年的时间，我觉得不能说对这门语言理解的有多深刻，只是在看了众多的经典书籍和博客之后，也想把自己的理解和总结也分享出来。

闭包

很多编程语言(Golang, Python, Javascript)都有闭包，闭包是语言运行时当中的一个自然的结果，拿 Javascript 举例来说，下面是一个经典的闭包案例。

function out() {
  const name = "cyan";
  return function in() {
    console.log(name);
  }
}
const fn = out();
fn();
fn = null;

为什么会产生闭包？

拿 JS 来说，就是外层函数执行上下文的变量环境对象在内存中被内层函数的作用域链 [[scope]] 引用，而且根据 JS 垃圾回收机制并不会销毁这一引用，所以内层函数作用域才可以通过作用域链引用外层函数作用域的属性，所以才有了闭包这种自然结果。

闭包有什么意义？

给 JavaScript 函数增加高级特性，像函数式编程中柯里化函数 | 组合函数 | pipe | partial

闭包的负面价值：内存泄露

内存泄露，内存泄露的本质就是代码执行完毕之后，内存当中的内层函数对象和外层函数执行上下文的变量对象存在引用，但是根据 JavaScript 垃圾回收机制，并不会删除所以占据内存。造成了内存泄露。我们可以利用 JavaScript 垃圾回收机制去解决闭包的内存泄露问题。我们可以手动销毁内层函数，外层的变量对象没有了引用也会被销毁。如下 fn = null;

原型

JavaScript 是基于原型的语言，JavaScript 实现继承，实例化的时候是将多个对象（实例对象，原型对象，普通对象）进行使用原型链进行关联或者说链接来实现的。

具体来说，JavaScript 当中的所有函数在初始化的时候都有一个 prototype 属性，该属性指向的是原型对象，也就是通过调用构造函数创建的实例对象的原型，好处是我们可以预定义属性，方法。这些属性和方法会被实例对象所共享。

原型链本质和设计

原型最核心的部分就是整个 JavaScript 整个语言的原型设计。通过 github 上的一张神图，我们可以按照显式原型和隐式原型两条线来进行全面梳理 JavaScript 语言的原型设计。

显式原型路线是：无论是基本类型构造函数（Number, String, BigInt, Boolean, Symbol）还是除了 Object 引用类型构造函数(Array, Date, Function, RegExp，除了 Object)，还是其他自定义构造函数，都遵守：
构造函数.prototype.__proto__ 等于Object.prototype
Object.prototype.__proto__等于顶层原型 null 。

隐式原型路线是：无论是基本类型构造函数（Number, String, BigInt, Boolean, Symbol），还是引用类型构造函数(Array, Date, Function, RegExp，包括 Object)，还是其他自定义构造函数，都遵守：
构造函数.__proto__ 等于 Function.prototype
构造函数.__proto__.__proto__ 等于 Object.prototype

作用域

作用域决定这些变量在程序的哪个区域可以使用。作用域也同时决定了变量在程序中的可见性。

在 JavaScript 中，有函数作用域/全局作用域/eval 作用域/块级作用域, 这些作用域的本质就是执行上下文环境或者说执行上下文对象。举例来说，就是执行上下文环境中的变量对象 VO/活动对象 AO（函数上下文使用 AO 活动对象来收集变量，函数和形参的）。

作用域链

作用域链本质上就是上下文对象中的作用域链一个属性，具体来说，初始化一个函数执行上下文对象的作用域链属性时，会将函数执行上下文对象的 AO，压入到已保存作用域链属性的最顶端。这样以来，就形成了作用域链，那查找属性的时候，先从自己的 AO 活动对象找，一直沿着作用域链找到下一个 AO，直到找到 GO 为止。这也就是作用域链的由来和本质。

执行上下文

我们知道JavaScript 是解释性语言，代码是一段一段执行的，再执行到一段可执行代码的时候，就会创建执行上下文/执行上下文环境/执行上下文对象，JavaScript可执行代码有三种：全局代码，函数代码，eval代码，所以对应的执行上下文对象也就有三种，分别是全局执行上下文，函数执行上下文，eval执行上下文。这三种执行上下文对象都有三个属性，第一个是变量环境对象VO，第二个是作用域链Scope，第三个是this。

可以用一段代码的执行来更好的解释执行上下文:

var a = 1;
function out () {
    var name = "ryan";
    function in () {
        console.log(name);
    }
    return in()
}
out();

有这样的一段代码，var a = 1，有一个外层函数out，out函数当中定义 var name = 2，out外层函数当中有一个内层函数in，内层函数，打印外层函数作用域的变量name，返回内层函数的调用。外层先调用out，然后再调用in。

首先，JavaScript引擎会先创建GO就是global object全局对象，这个全局对象上，我们可以使用一些预定义的对象或者函数，比如：日期对象Date，数学对象 Math …… 开始执行后JavaScript引擎会拿到他的第一段可执行代码，全局代码，所以会先创建全局执行上下文对象，并且将执行上下文 push 到调用栈当中，这时开始初始化全局上下文对象。初始化这个对象就是初始化三个属性：作用域链属性，VO变量对象，绑定this。

初始化作用域链：将JavaScript刚刚创建的GO保存为作用域链属性。

初始化VO：这个VO就是来收集定义的变量和函数的定义。这里就是全局定义的a属性和定义的out函数。

绑定this:这个就是this的绑定。

这时out函数被创建，保存全局上下文对象的作用链作为out函数的[[scope]]属性。调用out函数，然后创建out函数上下文对象，入栈，开始初始化out函数初始化上下文对象。

初始化AO活动对象：函数上下文当中叫AO（既可以收集定义的变量和函数，还能够收集函数的形参），全局当中我们是叫做VO。这里就是 name变量 和 in内部函数。

初始化作用域链：将out函数的[[scope]]属性赋值过来作为作用域链属性。再将out函数的 AO 对象压入out函数作用域链的最顶端。这样做的结果和目的就是，out函数开始执行查找属性和函数的时候，先在out函数的作用域的AO对象上找属性和方法，然后去GO上找属性和方法。

绑定this:还是函数的this绑定。

这时in函数被创建，保存out函数的作用链到in函数的[[scope]]属性，调用in函数，然后创建in函数上下文，入栈，开始初始化in函数初始化上下文对象。

初始化AO活动对象：这里没有初始化代码。

初始化作用域链：将in函数的[[scope]]属性赋值过来作为作用域链属性。再将in函数的AO对象压入in函数作用域链的最顶端。这样做的结果就很明确，in函数开始执行查找属性和函数的时候，先是自己的AO，然后是out函数的AO，最后是全局上下文的GO。

绑定this:还是函数的this绑定。

执行完in之后出栈，out出栈，全局上下文出栈，执行完毕。

垃圾回收

JavaScript 不像 C/C++, 让程序员自己去调用函数来释放内存，go javascript Java 拥有自己的一套垃圾回收算法（GC）进行自动的内存管理。

垃圾回收有两种方法：标记清除、引用计数, 引用计数不太常用，标记清除较为常用。

引用计数算法

第一个就是早先的引用计数法，它的策略是跟踪记录每个变量值被使用的次数，当这个值的引用次数变为 0 的时候，说明没有其他对象引用他了，垃圾回收器会在运行的时候清理掉引用次数为 0 的垃圾对象。

缺点

循环引用的两个对象无法回收的问题，因为循环引用的两个对象的引用次数都不为 0。这样就会发生内存泄露

标记清除算法

第二个就是目前大多数浏览器的 JavaScript 引擎都在采用标记清除算法，就像它的名字一样，此算法分为标记和清除两个阶段。

垃圾收集器在运行时会给内存中的所有变量都加上一个标记，假设标记策略时全标记为 0。
然后从根对象开始遍历，把可达的对象也就是不是垃圾的节点改成 1。
清理所有标记为 0 的垃圾对象，销毁并回收它们所占用的内存空间
最后，把内存中对象的标记都修改为 0，等待下一轮垃圾回收。

优化垃圾清除算法的原因

如果单单是这样的算法会造成很多问题

JS 是单线程运行的，垃圾回收机制是微任务，这意味着一旦进入到垃圾回收，那么其它的运行的业务逻辑都要暂停; 另一方面垃圾回收其实是非常耗时间的操作
未进行优化的算法之前存在很多问题，比如内存碎片化的问题

标记清除算法优化

优化 1：标记整理（Mark-Compact）算法

垃圾清理之后，会存在大量不连续的内存碎片，所以在标记结束后，标记整理算法会将不需要清理的对象对向内存的一端移动。从而使得空闲内存块是连续的。

优化 2：分代式垃圾回收

V8 的垃圾回收策略主要基于分代式垃圾回收机制，V8 中将堆内存分为新生代和老生代两区域，两个区域采用不同的垃圾回收器也就是不同的策略管理垃圾回收。
新生代的对象为存活时间较短的对象，简单来说就是新产生的对象，通常只支持 1 ～ 8M 的容量，而老生代的对象为存活时间较长或常驻内存的对象，简单来说就是经历过新生代垃圾回收后还存活下来的对象，容量通常比较大。

新生代垃圾回收

新生代垃圾回收所依赖的算法是Scavenge算法。
首先将新生代内存空间一分为二:分为使用区和空闲区，当进行垃圾回收时，V8 将使用区部分的对象检查一遍，如果是存活对象那么按照内存顺序排列并复制到空闲区内存中，如果是非存活对象直接回收即可。当所有的使用区中的存活对象按照顺序进入到空闲区内存之后，空闲区和使用区两者的角色对调，空闲区现在被闲置，使用区为正在使用，如此循环。

老生代垃圾回收

老生代垃圾回收所依赖的算法是标记清除算法。
新生代中的变量如果经过多次回收之后依然存在，会采用对象晋升策略，放入到老生代内存中。
老生代当中就是先使用标记清除算法来进行垃圾回收，然后再通过标记整理来解决内存碎片化问题。

优化 3：增量标记

将垃圾回收任务分为很多小的部分完成，每做完一个小的部分就让 JavaScript 应用逻辑执行一会儿，然后再做下面的部分，如此循环，直到任务完成。

事件循环

所有的任务都会被放到调用栈等待主线程执行，同步任务会在调用栈中按照顺序等待主线程依次执行，异步任务（将 DOM 操作，HTTP 请求，定时器等的回调函数）会在异步任务有了结果后，将注册的回调函数放入任务队列中等待主线程空闲的时候（调用栈被清空），通过轮询来读取异步任务到调用栈内等待主线程的执行。

从宏任务和微任务的角度来聊 JavaScript 事件循环？

MacroTask（宏任务）
- script 全部代码(普通任务)、setTimeout、setInterval、setImmediate、I/O、UI Rendering。
MicroTask（微任务）
- Process.nextTick（Node 独有）、Promise、MutationObserver、垃圾回收

在每一个宏任务中会定义一个微任务队列，当该宏任务执行完成，会检查其中的微任务队列，如果为空则直接执行下一个宏任务，如果不为空，则依次执行微任务，执行完成才去执行下一个宏任务。

node 事件循环和浏览器事件循环的区别是什么？

两者最主要的区别在于浏览器中的微任务是在每个相应的宏任务中执行的，（在执行下一个宏任务的时候会清空微任务队列）而 nodejs 中的微任务是在不同阶段之间执行的。

node 的初始化
- 初始化 node 环境。
- 执行输入代码。
- 执行 process.nextTick 回调。
- process.nextTick 是一个独立于 eventLoop 的任务队列。在每一个 eventLoop 阶段完成后会去检查这个队列，如果里面有任务，会让这部分任务优先于微任务执行。所以在 nodejs 事件循环的每一个子阶段退出之前都会按顺序执行如下过程：
  1. 检查是否有 process.nextTick 回调，如果有，全部执行。
  2. 检查是否有 microtaks，如果有，全部执行。
  3. 退出当前阶段。
- 执行 microtasks。
进入 event-loop
- 进入 timers 阶段
  - 检查 timer 队列是否有到期的 timer 回调，如果有，将到期的 timer 回调按照 timerId 升序执行。这些定时器就是 setTimeout、setInterval
  - 检查是否有 process.nextTick 任务，如果有，全部执行。
  - 检查是否有 microtask，如果有，全部执行。
  - 退出该阶段。
- 进入IO callbacks阶段。
  - 检查是否有 pending 的 I/O 回调。如果有，执行回调。如果没有，退出该阶段。
  - 检查是否有 process.nextTick 任务，如果有，全部执行。
  - 检查是否有 microtask，如果有，全部执行。
  - 退出该阶段。
- 进入 poll /轮询阶段
  - 首先检查是否存在尚未完成的回调，如果存在，那么分两种情况。
    - 第一种情况：
      - 如果有可用回调（可用回调包含到期的定时器还有一些 IO 事件等），执行所有可用回调。
      - 检查是否有 process.nextTick 回调，如果有，全部执行。
      - 检查是否有 microtaks，如果有，全部执行。
      - 退出该阶段。
    - 第二种情况：
      - 如果没有可用回调。
      - 检查是否有 immediate 回调，如果有，退出 poll 阶段，进入 check 阶段。
    - 所以 immediate 的回调的调用顺序是不一定的。
  - 如果不存在尚未完成的回调，退出 poll 阶段。
- 进入 check 阶段。
  - 如果有 immediate 回调，则执行所有 immediate 回调。
  - 检查是否有 process.nextTick 回调，如果有，全部执行。
  - 检查是否有 microtaks，如果有，全部执行。
  - 退出 check 阶段
- 进入 closing 阶段 / 关闭事件的回调阶段。 > 如果一个 socket 或句柄（handle 文件/设备/套接字）被突然关闭，例如 socket.destroy()， close 事件的回调就会在这个阶段执行。
  - 如果有 immediate 回调，则执行所有 immediate 回调。
  - 检查是否有 process.nextTick 回调，如果有，全部执行。
  - 检查是否有 microtaks，如果有，全部执行。
  - 退出 closing 阶段
- 进行下一轮事件循环

模块化

JavaScript 模块化历史

1. 刀耕火种

defer 与 async 的区别是：defer 要等到整个页面在内存中正常渲染结束（DOM 结构完全生成，以及其他脚本执行完成），才会执行；async 一旦下载完，排版引擎就会中断渲染，执行这个脚本以后，再继续渲染。一句话，defer 是“渲染完再执行”，async 是“下载完就执行”。另外，如果有多个 defer 脚本，会按照它们在页面出现的顺序加载，而多个 async 脚本是不能保证加载顺序的。

在原始 JavaScript 中，出现模块化规范之前，js 文件之间的通信基本上靠的是 window 对象。我们按照 js 文件之间依赖关系来按顺序引入 js。一旦顺序没有按照依赖关系来引入，就会报错。

// 引入顺序颠倒就会报错

  
  


// a.js
var nameP = "ryan";
// b.js
console.log(nameP);

所以当业务变得复杂时,就会产生很多问题：

第一个问题：多而复杂的 js 文件不好开发和维护，需要考虑 js 文件之间的依赖关系。
第二个问题：window上挂载的全局变量避免不了存在命名冲突、占用内存无法被回收、代码可读性低等诸多问题。
如果按照这么来开发前端，开发体验会非常糟糕。

所以尽管当时没有模块化的时候，但也涌现出了一些解决方案。

解决方案 1：函数

function m1() {
  //...
}

function m2() {
  //...
}

将不同的功能函数当成一个个模块，这样做虽然起到了一定的效果，但是还是避免不了存在命名冲突，最重要的是，这些函数被当作模块，我们看不出来模块之间的关系。

解决方案 2：对象

var module1 = new Object({
  _count: 0,

  m1: function () {
    //...
  },

  m2: function () {
    //...
  },
});

将不同的功能对象当成一个个模块，这样做虽然起到了一定的效果，但是还是避免不了存在命名冲突，最重要的是，这样的写法会暴露所有的模块成员。模块成员可以被随意修改。

解决方案 3：IIFE（匿名立即执行函数）

// a.js
var moduleA = (function () {
  return {
    name: "ryan",
  };
})();
//console.log(moduleA.name); ryan

随着前端业务增重，代码越来越复杂，前端急需一种清晰有效方案来处理功能模块之间的依赖关系。

2. AMD 和 CMD

node 服务器端编程出来的时候，模块系统就是参照 CommonJs 规范实现的，所以有了服务器端模块化规范，大家也想要客户端模块化开发，而且大家也希望两者可以相互兼容，但是 CommonJs 对客户端模块化来说，一个非常大的局限就是：同步加载模块的方式不适合浏览器环境，因为同步加载模块会导致浏览器卡死，阻塞渲染，所以在这样的背景下 AMD 这种异步加载模块化的方式出现了。

CMD 和 AMD 一样，都是 JS 的社区模块化规范，主要应用于浏览器端，可以异步加载模块。

我们只要按照规范的方式去书写，就可以被 require.js, sea.js 正确解析。从而实现异步模块化。

比如 require.js 中的 require 函数，define 函数
sea.js的require函数

AMD

例子来自于 yayu

require.js

// main.js
require(["./add", "./square"], function (addModule, squareModule) {
  console.log(addModule.add(1, 1));
  console.log(squareModule.square(3));
});

// add.js
define(function() {
    console.log('加载了 add 模块');
    var add = function(x, y) { 
        return x + y;
    };

    return {      
        add: add
    };
});
// multiply.js
define(function() {
    console.log('加载了 multiply 模块')
    var multiply = function(x, y) { 
        return x * y;
    };

    return {      
        multiply: multiply
    };
});
// square.js
define(['./multiply'], function(multiplyModule) {
    console.log('加载了 square 模块')
    return {      
        square: function(num) {
            return multiplyModule.multiply(num, num)
        }
    };
});
// 加载了 add 模块
// 加载了 multiply 模块
// 加载了 square 模块
// 2
// 9

CMD

sea.js

// main.js
define(function(require, exports, module) {
    var addModule = require('./add');
    console.log(addModule.add(1, 1))

    var squareModule = require('./square');
    console.log(squareModule.square(3))
});

// add.js
define(function(require, exports, module) {
    console.log('加载了 add 模块')
    var add = function(x, y) { 
        return x + y;
    };
    module.exports = {      
        add: add
    };
});
// square.js
define(function(require, exports, module) {
    console.log('加载了 square 模块')
    var multiplyModule = require('./multiply');
    module.exports = {      
        square: function(num) {
            return multiplyModule.multiply(num, num)
        }
    };

});

// multiply.js
define(function(require, exports, module) {
    console.log('加载了 multiply 模块')
    var multiply = function(x, y) { 
        return x * y;
    };
    module.exports = {      
        multiply: multiply
    };
});

// 加载了 add 模块
// 2
// 加载了 square 模块
// 加载了 multiply 模块
// 9

AMD 与 CMD 的区别

yayu 总结的区别：

根据上面代码的打印结果，我们也可以更好的理解他们之间的区别

CMD 推崇依赖就近，AMD 推崇依赖前置。
AMD 是将需要使用的模块全部加载完再执行代码，而CMD 是在 require 的时候才去加载模块文件，加载完再接着执行。

CommonJS(CJS)

CommonJS 基本说明

随着 node 诞生，服务器端的模块规范 CommonJS 被创建出来。在 commonjs 中每一个 js 文件都是一个单独的模块，我们在控制台也可以打印出这个 module 对象。所有代码都运行在模块作用域，不会污染全局作用域。同时，CommonJS 是运行时同步加载模块，比较适合服务器端的模块加载，因为服务器的模块文件都在硬盘，即使是同步也非常快。

CJS 基本用法

导入

const a = require("./a.js");
// a是module.exports导出的对象。

导出

// 为module.exports对象上添加属性。
exports.name = "kobe";
exports.age = 18;
// 重置了module.exports对象引用。
module.exports = {};
// 导出module.exports对象

cjs 模块导入导出的基本原理

module.exports = {};
exports = module.exports;

require 引入细节

情况一：X 是一个 Node 核心模块，比如path、http。
- 直接返回核心模块，并且停止查找。
情况二：X 是以 ./ 或 ../ 或 /（根目录）开头的。
- 第一步：将 X 当做一个文件在对应的目录下查找。
  - 如果有后缀名，按照后缀名的格式查找对应的文件
  - 如果没有后缀名，会按照如下顺序：按照 js -> json -> node的顺序。
- 第二步：没有找到对应的文件，将 X 作为一个目录。
  - 作为目录下查找 index.js -> .json -> .node。

ES6module(ESM)

AMD 、 CMD 等都是在原有 JS 语法的基础上二次封装的一些社区规范，ES6 module是 JavaScript 语言层面的规范，ES6 module编译时静态加载。编译时就能确定模块的依赖关系，以及输入和输出的变量。从而我们可以在编译时进行静态优化，而像 AMD, CMD 运行时加载，导致完全没办法在编译时做“静态优化”。

ES6module 与 CommonJS 的区别

CommonJS 模块输出的是一个值的拷贝对于引用类型而言就是引用，ES6 模块输出的无论是什么类型都是值的引用。
CommonJS /模块是运行时加载，ES6module 是编译时就能确定模块的依赖关系和输入输出的接口。

ES6module 与 CommonJS 导出简单值

// 输出模块 counter.js -> 简单值
var counter = 3;
function incCounter() {
  counter++;
}
module.exports = {
  counter: counter,
  incCounter: incCounter,
};
// 引入模块 main.js
var mod = require("./counter");

console.log(mod.counter); // 3
mod.incCounter();
console.log(mod.counter); // 3

ES6 module 模块输出的无论是什么类型都是值的引用。

// counter.js
export let counter = 3;
export function incCounter() {
  counter++;
}

// main.js
import { counter, incCounter } from "./counter";
console.log(counter); // 3
incCounter();
console.log(counter); // 4

CommonJS 导出引用值

// 输出模块 counter.js -> 引用值
var counter = {
  value: 3,
};

function incCounter() {
  counter.value++;
}
module.exports = {
  counter: counter,
  incCounter: incCounter,
};
// 引入模块 main.js
var mod = require("./counter.js");

console.log(mod.counter.value); // 3
mod.incCounter();
console.log(mod.counter.value); // 4

ES Module 的解析流程

阶段一： 构建（Construction），根据所有依赖关系去查找 js 文件，并且下载，将其解析成模块记录（Module Record）

阶段二： 实例化（Instantiation），对模块记录进行实例化为模块环境记录，这时 import 会自动提升到代码的顶层。开始解析模块的导入和导出语句。并且为 bindings 的值（也就是导出的变量）分配内存空间。

阶段三： 运行（Evaluation），运行代码，计算值，并且赋值到导出变量对应的内存地址中，以供导入消费。

导入的模块不可以修改值，因为在模块环境记录当中用的是 const，修改就会报错。

export 用法

export const name = 'why';
export const age = 18;
export { name, age, foo };
export { name as fName, age as fAge, foo as fFoo };

// 直接导出,无需先引入。
export { add, sub } from './math.js';
export { timeFormat, priceFormat } from './format.js';
export * from './math.js';
export * from './format.js';

// 默认导出
export default foo;

import 用法

import { name, age } from './foo.js';
import { name as fName, age as fAge, foo as fFoo } from './foo.js';
import * as foo from './foo.js';

// 默认导出的引入
import why from './foo.js';

// 动态引入
import('./foo.js').then((res) => {
  console.log('res:', res.name);
});

CommonJS 模块的循环加载

CommonJS 模块的重要特性是加载时执行，即脚本代码在require的时候，就会全部执行。一旦出现某个模块被"循环加载"，就只输出已经执行的部分，还未执行的部分不会输出，从而解决 cjs 模块的循环加载。

让我们来看，Node 官方文档里面的例子。脚本文件a.js代码如下。

exports.done = false;
var b = require('./b.js');
console.log('在 a.js 之中，b.done = %j', b.done);
exports.done = true;
console.log('a.js 执行完毕');

上面代码之中，a.js脚本先输出一个done变量，然后加载另一个脚本文件b.js。注意，此时a.js代码就停在这里，等待b.js执行完毕，再往下执行。

再看b.js的代码。

exports.done = false;
var a = require('./a.js');
console.log('在 b.js 之中，a.done = %j', a.done);
exports.done = true;
console.log('b.js 执行完毕');

上面代码之中，b.js执行到第二行，就会去加载a.js，这时，就发生了“循环加载”。系统会去a.js模块对应对象的exports属性取值，可是因为a.js还没有执行完，从exports属性只能取回已经执行的部分，而不是最后的值。

a.js已经执行的部分，只有一行。

exports.done = false;

因此，对于b.js来说，它从a.js只输入一个变量done，值为false。

然后，b.js接着往下执行，等到全部执行完毕，再把执行权交还给a.js。于是，a.js接着往下执行，直到执行完毕。我们写一个脚本main.js，验证这个过程。

var a = require('./a.js');
var b = require('./b.js');
console.log('在 main.js 之中, a.done=%j, b.done=%j', a.done, b.done);

执行main.js，运行结果如下。

$ node main.js

在 b.js 之中，a.done = false
b.js 执行完毕
在 a.js 之中，b.done = true
a.js 执行完毕
在 main.js 之中, a.done=true, b.done=true

上面的代码证明了两件事。一是，在b.js之中，a.js没有执行完毕，只执行了第一行。二是，main.js执行到第二行时，不会再次执行b.js，而是输出缓存的b.js的执行结果，即它的第四行。

exports.done = true;

总之，CommonJS 输入的是被输出值的拷贝，不是引用。

另外，由于 CommonJS 模块遇到循环加载时，返回的是当前已经执行的部分的值，而不是代码全部执行后的值，两者可能会有差异。所以，输入变量的时候，必须非常小心。

var a = require('a'); // 安全的写法
var foo = require('a').foo; // 危险的写法

exports.good = function (arg) {
  return a.foo('good', arg); // 使用的是 a.foo 的最新值
};

exports.bad = function (arg) {
  return foo('bad', arg); // 使用的是一个部分加载时的值
};

上面代码中，如果发生循环加载，require('a').foo的值很可能后面会被改写，改用require('a')会更保险一点。

ES6 模块的循环加载

ES6 处理“循环加载”与 CommonJS 有本质的不同。ES6 模块是动态引用，如果使用import从一个模块加载变量（即import foo from 'foo'），那些变量不会被缓存，而是成为一个指向被加载模块的引用，需要开发者自己保证，真正取值的时候能够取到值，

请看下面这个例子。

// a.mjs
import { bar } from './b';
console.log('a.mjs');
console.log(bar);
export let foo = 'foo';

// b.mjs
import { foo } from './a';
console.log('b.mjs');
console.log(foo);
export let bar = 'bar';

上面代码中，a.mjs加载b.mjs，b.mjs又加载a.mjs，构成循环加载。执行a.mjs，结果如下。

$ node --experimental-modules a.mjs
b.mjs
ReferenceError: foo is not defined

上面代码中，执行a.mjs以后会报错，foo变量未定义，这是为什么？

让我们一行行来看，ES6 循环加载是怎么处理的。首先，执行a.mjs以后，引擎发现它加载了b.mjs，因此会优先执行b.mjs，然后再执行a.mjs。接着，执行b.mjs的时候，已知它从a.mjs输入了foo接口，这时不会去执行a.mjs，而是认为这个接口已经存在了，继续往下执行。执行到第三行console.log(foo)的时候，才发现这个接口根本没定义，因此报错。

解决这个问题的方法，就是让b.mjs运行的时候，foo已经有定义了。这可以通过将foo写成函数来解决。

// a.mjs
import { bar } from './b';
console.log('a.mjs');
console.log(bar());
function foo() {
  return 'foo';
}
export { foo };

// b.mjs
import { foo } from './a';
console.log('b.mjs');
console.log(foo());
function bar() {
  return 'bar';
}
export { bar };

这时再执行a.mjs就可以得到预期结果。

$ node --experimental-modules a.mjs
b.mjs
foo
a.mjs
bar

这是因为函数具有提升作用，在执行import {bar} from './b'时，函数foo就已经有定义了，所以b.mjs加载的时候不会报错。这也意味着，如果把函数foo改写成函数表达式，也会报错。

// a.mjs
import { bar } from './b';
console.log('a.mjs');
console.log(bar());
const foo = () => 'foo';
export { foo };

上面代码的第四行，改成了函数表达式，就不具有提升作用，执行就会报错。

我们再来看 ES6 模块加载器SystemJS给出的一个例子。

// even.js
import { odd } from './odd';
export var counter = 0;
export function even(n) {
  counter++;
  return n === 0 || odd(n - 1);
}

// odd.js
import { even } from './even';
export function odd(n) {
  return n !== 0 && even(n - 1);
}

上面代码中，even.js里面的函数even有一个参数n，只要不等于 0，就会减去 1，传入加载的odd()。odd.js也会做类似操作。

运行上面这段代码，结果如下。

$ babel-node
> import * as m from './even.js';
> m.even(10);
true
> m.counter
6
> m.even(20)
true
> m.counter
17

上面代码中，参数n从 10 变为 0 的过程中，even()一共会执行 6 次，所以变量counter等于 6。第二次调用even()时，参数n从 20 变为 0，even()一共会执行 11 次，加上前面的 6 次，所以变量counter等于 17。

这个例子要是改写成 CommonJS，就根本无法执行，会报错。

// even.js
var odd = require('./odd');
var counter = 0;
exports.counter = counter;
exports.even = function (n) {
  counter++;
  return n == 0 || odd(n - 1);
};

// odd.js
var even = require('./even').even;
module.exports = function (n) {
  return n != 0 && even(n - 1);
};

上面代码中，even.js加载odd.js，而odd.js又去加载even.js，形成“循环加载”。这时，执行引擎就会输出even.js已经执行的部分（不存在任何结果），所以在odd.js之中，变量even等于undefined，等到后面调用even(n - 1)就会报错。

$ node
> var m = require('./even');
> m.even(10)
TypeError: even is not a function

类型

类型检测

typeof

typeof 一般检测简单数据类型，返回值是简单数据类型的字符串如; "number"， "boolean"，

"string" 检测引用数据类型的时候除了函数类型正常返回"function"，其余都返回"object"。

typeof 可以检测返回 8 种数据类型也就是typeof 可以返回 8 种数据类型的字符串：undefined， boolean， string， number， object， function，symbol， bigint。

console.log(typeof 1); // 'number'
console.log(typeof "1"); // 'string'
console.log(typeof function () {}); // 'function'
console.log(typeof true); // 'boolean'
console.log(typeof null); // 'object'
console.log(typeof undefined); // 'undefined'
console.log(typeof { name: "ryan" }); // 'object'
console.log(typeof new String("hello")); // 'object'
console.log(typeof new String(1)); // 'object'
console.log(typeof 120n); // 'bigint'
console.log(typeof Symbol()); // 'symbol'
// 由此可见typeof对于基本数据类型的检测是okay的。

typeof检测null的时候，也会返回'object', 出现这种情况的原因其实是JavaScript最初是通过 32 位 bit 来存储值，值的低三位或者低一位被当作类型标签来识别数据类型（000：被识别为对象，1：被识别为 31 位的有符号位整数，110：被识别位布尔值，110：被识别为字符串，010：被识别为双精度的浮点数），而恰巧对象和 null 的低三位都是 000，且000的类型标签是对象，所以 null 也被处理为对象。从技术层面来将，我认为还是挺合理的，因为特殊值null一直被我们认为是一个空对象的引用。

instanceof

instanceof 一般检测引用数据类型，返回值是布尔值，用来判断构造函数的原型对象 prototype 是否存在于实例对象的原型链上。

对于基本数据类型不能准确判断:

111 instanceof Number -> false 同样的还有"xx"和true, 因为字面量值不是实例, 通过new构造函数构造出来的才是，new Number()才是

console.log('instanceof 系列');
console.log('instanceof 系列' instanceof String); // false
console.log([2， 3] instanceof Array); // true
console.log(1 instanceof Number); // false
console.log({ name: 'ryan' } instanceof Object); // true
console.log(function () {} instanceof Function); // true
console.log(true instanceof Boolean); // false
console.log(new String('hello') instanceof String); // true
// 由此可以看出instanceof检测简单数据类型都时候都返回false， 除非你将简单值进行类包装如: new String('')

Object.prototype.toString.call()

可以检测 14 个数据类型，检测数据类型的神器

function.call(thisArg， arg1， arg2， ...) // 第一个是可选参数。
console.log(Object.prototype.toString.call(new Number(1)));
console.log(Object.prototype.toString.call('hello'));
console.log(Object.prototype.toString.call(new String('hello')));
console.log(Object.prototype.toString.call(console.log));
console.log(Object.prototype.toString({}));
console.log(Object.prototype.toString.call([]));
console.log(Object.prototype.toString.call(new Date()));
console.log(Object.prototype.toString.call(Math));
console.log(Object.prototype.toString.call(JSON));
console.log(Object.prototype.toString.call(undefined))
console.log(Object.prototype.toString.call(null))
console.log(Object.prototype.toString(null))
console.log(Object.prototype.toString(undefined))
//[object Number]
//[object String]
//[object String]
//[object Function]
//[object Object]
//[object Array]
//[object Date]
//[object Math]
//[object JSON]
//[object Undefined]
//[object Null]
// [object Object]
//[object Object]
//如果非要挑一挑毛病，那就是方法返回的字符串可能没有像typeof一样
// 值得注意的是，Object.prototype.toString(null | undefined) 返回的是 [object Object]

constructor

constructor有两个作用，一是判断数据的类型，二是对象实例通过 constrcutor 对象访问它的构造函数。

需要注意。如果创建一个对象来改变它的原型，constructor就不能用来判断数据类型了。（也非常好理解，因为实例上没有constructor属性，实例找该属性是通过实例的原型对象来找的，所以当原型对象改变了，找到的构造函数就改变了）

console.log((2).constructor === Number); // true
console.log((true).constructor === Boolean); // true
console.log(('str').constructor === String); // true
console.log(([]).constructor === Array); // true
console.log((function() {}).constructor === Function); // true
console.log(({}).constructor === Object); // true

类型转换

分为显示类型转换和隐式类型转换

原始值转换为布尔值

原始值转换为布尔值: 只有六种值会被转换为 false, 其他都是 true.
- 0, NaN, null, '', undefined, false

原始值转换为数字

原始值转换为数字: Number()如果不传值默认返回 0, 如果传了值调用调用 ToNumber(value), ToNumber 是底层规范实现。

| 参数类型 | 结果 | | --- | --- | | undefined | NaN | | Null | +0 | | Boolean | 如果参数是 true，返回 1。参数为 false，返回 +0 | | Number | 返回与之相等的值 | | String | 如下段解释 |
对于 Number(string) 会试着将包含数值字符, 加号,减号的字符串转换成浮点数或者是整数, 也可以识别 8 进制的 0 和 16 进制的 0x,会忽略前导的 0 进行转换, 如果有一个字符不是数字直接返回 NaN, 也就是不符合上述的情况直接返回 NaN.

console.log(Number(undefined)); // NaN
console.log(Number(null)); // 0
console.log(Number(1)); // 1
console.log(Number(true)); // 1
console.log(Number(NaN)); // NaN
console.log(Number("123j")); // NaN

鉴于这种严格的转换数字规则, 我们一般会使用更加灵活的 parseInt() 和 parseFloat()进行转换,他们更专注于字符串当中是否包含数值模式
parseInt(string, [radix]); 只解析整数, parseFloat(string, [radix])既可以解析整数也可以解析浮点数, parseInt 和 parseFloat 都会跳过任意数量的前导空格，尽可能解析更多数值字符，并忽略后面的内容。如果第一个非空格字符是非法的数字直接量，将最终返回 NaN：parseFloat会专注于浮点数的第一次出现, 第二次就会忽略浮点数

console.log(parseInt("1a2"));
console.log(parseInt("0001a2"));
console.log(parseInt("-0001a2"));
console.log(parseInt("-z0001a2"));
console.log(parseInt("+0.001a2"));
console.log(parseInt("1.001a2"));
console.log(parseFloat("1.001a2.30"));
console.log(parseInt(070));
// 1
// 1
// -1
// NaN
// 0
// 1
// 1.001
// 56

原始值转换为字符串

如果 String 函数不传参数，返回空字符串，如果有参数，调用 ToString(value)，而 ToString 也给了一个对应的结果表。

参数类型	结果
Undefined	"undefined"
Null	"null"
Boolean	如果参数是 true，返回 "true"。参数为 false，返回 "false"
Number	num.toString() 括号当中可以选择进制, 默认是 10 进制
String	返回与之相等的值

null 和 undefined 没有 toString()方法, 所有我们会使用 String()方法, 如果有参数会调用 toString(), 如果参数是 null 和 undefined 返回字符串, 相当于是 toString()的增强版 -- 注意这里的 toString()和ToString(value) 不一样, 一个是对外暴露的, 一个是不对外暴露的顶层规范

如果 String(对象类型)那么会调用 toPrimitive(input, String)方法,返回一个基本类型的值, 然后在通过ToString对基本类型进行转换

原始值转换为对象

可以通过构造函数 String(), Boolean(), 来将原始值转换为包装对象

对象转化为字符串

console.log(Array.prototype.toString === [1, 1].toString, "布尔值"); // true

({ a: 1 }.toString === Object.prototype.toString); // true

每个类型在调用自己身上的 toString 方法时的一些规则

toString()

从上述代码我们可以看出来,当调用对象的 toString 方法的时候, 他会调用对应对象上的 toString 方法。

数组的 toString 方法将每个数组元素转换成一个字符串，并在元素之间添加逗号后合并成结果字符串。
函数的 toString 方法返回源代码字符串。
日期的 toString 方法返回一个可读的日期和时间字符串。
RegExp 的 toString 方法返回一个表示正则表达式直接量的字符串。
如果 String(对象类型)那么会调用 toPrimitive(input, String)方法,返回一个基本类型的值, 然后在通过ToString对基本类型进行转换

console.log(function a() {}.toString());
console.log({ a: "ryan" }.toString());
console.log([1, 3, 34].toString());
console.log(new Date().toString());
console.log(/^a$/.toString());
//function a() {}
//[object Object]
//'1,3,34'
//Sat Jan 08 2022 12:52:09 GMT+0800 (中国标准时间)
//^a$/

valueOf

另一个转换对象的函数是 valueOf，表示对象的原始值。默认的 valueOf 方法返回这个对象本身，数组、函数、正则简单的继承了这个默认方法，也会返回对象本身。日期是一个例外，它会返回它的一个内容表示: 1970 年 1 月 1 日以来的毫秒数。

console.log(function a() {}.valueOf());
console.log({ a: "ryan" }.valueOf());
console.log([1, 3, 34].valueOf());
console.log(new Date().valueOf());
console.log(/^a$/.valueOf());
// [Function: a]
// { a: 'ryan' }
// [ 1, 3, 34 ]
// 1641620212097
// /^a$/

对象转换为数字

如果 Number(对象类型)那么会调用 toPrimitive(input, Number)方法,返回一个基本类型的值, 然后在通过ToNumber对基本类型进行转换

ToPrimitive()

ToPrimitive(input[, PreferredType]) []表示可选参数

第一个参数是 input，表示要处理的输入值。
第二个参数是 PreferredType，非必填，表示希望转换成的类型，有两个值可以选，Number 或者 String。
当不传入 PreferredType 时，如果 input是日期类型，相当于传入 String，否则，都相当于传入 Number。
如果传入的 input 是 Undefined、Null、Boolean、Number、String 类型，直接返回该值。// 如果是原始值直接返回

ToPrimitive(obj, Number)

如果是 ToPrimitive(obj, Number)，处理步骤如下：
1. 如果 obj 为基本类型，直接返回
2. 否则，调用 valueOf 方法，如果返回一个原始值，则 JavaScript 将其返回。
3. 否则，调用 toString 方法，如果返回一个原始值，则 JavaScript 将其返回。
4. 否则，JavaScript 抛出一个类型错误异常。

ToPrimitive(obj, String)

如果是 ToPrimitive(obj, String)，处理步骤如下：
1. 如果 obj 为基本类型，直接返回
2. 否则，调用 toString 方法，如果返回一个原始值，则 JavaScript 将其返回。
3. 否则，调用 valueOf 方法，如果返回一个原始值，则 JavaScript 将其返回。
4. 否则，JavaScript 抛出一个类型错误异常。

console.log(Number({})); // NaN
console.log(Number({ a: 1 })); // NaN

console.log(Number([])); // 0
console.log(Number([0])); // 0
console.log(Number([1, 2, 3])); // NaN
console.log(
  Number(function () {
    var a = 1;
  })
); // NaN
console.log(Number(/\d+/g)); // NaN
console.log(Number(new Date(2010, 0, 1))); // 1262275200000
console.log(Number(new Error("a"))); // NaN

JSON.toStringify()

处理基本类型时，与使用 toString 基本相同，结果都是字符串，除了 undefined
布尔值、数字、字符串的包装对象在序列化过程中会自动转换成对应的原始值。
undefined、任意的函数以及 symbol 值，在序列化过程中会被忽略（出现在非数组对象的属性值中时）或者被转换成 null（出现在数组中时）。

// 在对象当中和在数组当中的不同表现
JSON.stringify({ x: undefined, y: Object, z: Symbol("") });
// "{}"
JSON.stringify([undefined, Object, Symbol("")]);
// "[null,null,null]"

JSON.stringify 有第二个参数 replacer，它可以是数组或者函数，用来指定对象序列化过程中哪些属性应该被处理，哪些应该被排除。

//数组和函数当中的不同体现
function replacer(key, value) {
  if (key == "name") {
    return undefined;
  }
  return value;
}
JSON.toStringify({ name: "ryan", age: 18 }, replacer);
var foo = { foundation: "Mozilla", model: "box", week: 45, transport: "car", month: 7 };
console.log(JSON.stringify(foo, ["week", "month"]));
// {"week":45,"month":7}

如果一个被序列化的对象拥有 toJSON 方法，那么该 toJSON 方法就会覆盖该对象默认的序列化行为：不是那个对象被序列化，而是调用 toJSON 方法后的返回值会被序列化，例如：

// toJSON返回值被序列化
var obj = {
  foo: "foo",
  toJSON: function () {
    return "bar";
  },
};
JSON.stringify(obj); // '"bar"'
JSON.stringify({ x: obj }); // '{"x":"bar"}'

隐式转换

一元操作符

当一元操作符 + 操作的是原始值 Number(原始值)
当一元操作符 + 操作的是引用类型 → ToPrimitive(引用值, Number) -> 根据 ToNumber 规范求值

console.log(+["1"]); // 1
console.log(+["1", "2", "3"]); // NaN
console.log(+{}); // NaN
console.log(+"1"); // 1

二元操作符

当计算 value1 + value2 时：

0lprim = ToPrimitive(value1)
rprim = ToPrimitive(value2)
如果 lprim 是字符串或者 rprim 是字符串或者都是字符串，那么返回 ToString(lprim) 和 ToString(rprim)的拼接结果
要是不满足那么就返回 ToNumber(lprim) 和 ToNumber(rprim)的运算结果

console.log(null + 1); // 1
console.log([] + []); // ''
console.log([] + {}); // '[object Object]'
console.log(1 + true); // 2
console.log({} + {}); // '[object Object][object Object]'
console.log(new Date(2017, 04, 21) + 1); // 这个知道是数字还是字符串类型就行

x == y 相等

当 x 和 y 是同一类型的时候:
- x 和 y 是 null 和 undefined 时返回 true
- x 和 y 是字符串的时候, 只有字符串完全相同的时候返回 true, 否则返回 false
- x 和 y 是数字的时候, 两个 NaN 在比较的时候, 返回 false, 数字相等的时候返回 true, +0 0 -0 之间的比较是 true 其他是 false
- x 和 y 是对象的时候, 指向同一对象的时候返回 false
- x 和 y 是布尔值的时候, 都是 false 或者都是 true 的时候返回 true 其他返回 false
当 x 和 y 是不同的类型的时候
- x 和 y 一方是 null 另一方是 undefined 的时候返回 true
- x 和 y 有一方是字符串另一方是数字的时候, 会则会 ToNumber(字符串)来进行比较
- x 和 y 有一方是布尔值的时候, 将布尔值转换为数字进行比较
- x 和 y 有一方是数字或者是字符串的时候, 另一方是对象的时候. 会 Toprimitive(对象)进行比较
- 其他返回 false

console.log(false == "0");
console.log(false == 0);
console.log(false == "");

console.log("" == 0);
console.log("" == []);

console.log([] == 0);

console.log("" == [null]);
console.log(0 == "\n");
console.log([] == 0);
// 都是false要值得注意的是 [null | undefined].toString() 结果是 ''[null, null, null, undefined].toString() j结果是 ',,,'

对于`<`和`>`比较符

如果两边都是字符串，则比较字母表顺序：

'ca' < 'bd' // false

'a' < 'b' // true

其他情况下，转换为数字再比较：

'12' < 13 // true

false > -1 // true

而引用类型会被ToPrimitive(obj, Number)转换为基本类型再进行转换：

var a = {}

a > 2 // false

NaN 和数字比，比不出来结果

类型相关面试题

为什么 0.1+0.2 ! == 0.3？如何解决？

计算机运算器在做加和的时候，是将 10 进制的 0.1 + 0.2 转换为 2 进制的 0.1 + 0.2 进行加和。由于 0.1 和 0.2 在转换为二进制的时候会无限循环 (0.1转换为二进制，乘以二发现永远都乘不到整数)，且 JavaScript Number类型的实现遵循 IEEE 754标准：1 位存符号位 sign ，11 位存指数位 exponent ，52 位使用原码来存储尾数位Fraction。所以二进制的 0.1 和 0.2 在 52 位之后二进制位会被截掉，即在保存的时候就已经出现了精度的丢失。最后，精度丢失的两个二进制数经过对阶、尾数运算、规格化、舍入处理相加之后再转变为 10 进制也就出现了0.1 + 0.2 = 0.30000000000000004440892098500626的结果。

let n1 = 0.1, n2 = 0.2
console.log(n1 + n2)  // 0.30000000000000004
(n1 + n2).toFixed(2) // 注意，toFixed为四舍五入

//利用误差属性
function numberepsilon(arg1,arg2){
  return Math.abs(arg1 - arg2) < Number.EPSILON;
}

console.log(numberepsilon(0.1 + 0.2, 0.3)); // true

|| 和 && 和？？操作符的返回值？

|| 和 && 首先会对第一个操作数执行条件判断，如果其不是布尔值就先强制转换为布尔类型，然后再执行条件判断。

对于 || 来说，如果条件判断结果为 true 就返回第一个操作数的值，如果为 false 就返回第二个操作数的值。做变量赋值。
&& 则相反，如果条件判断结果为 true 就返回第二个操作数的值，如果为 false 就返回第一个操作数的值。做变量渲染。
?? 控制合并是一个逻辑运算符，当左侧的操作数为 null 或者 undefined 时，返回其右侧操作数，否则返回左侧操作数。

|| 和 && 返回它们其中一个操作数的值，而非条件判断的结果

= 和与 Object.is()的区别

对于 ==（双等号）来说，在隐式转换当中的例子当中我们也可以看到，如果 == 两边的类型不一致会先进行类型转换之后再比较，比如有布尔值就将布尔值转换为数字再进行比较，有字符串和数字就将字符串转换为数字再进行比较，
对于=== (三等号) 来说，如果出现两边类型不一致的情况直接返回 false.
Object.is（）是再三等号判断的基础上进行增强和完善，处理了特殊情况，比如在Object.is()中0 和 +0 不相等，两个 NaN 是相等的。这在三等号和双等号中 0 和 +0 相等，两个 NaN 不相等。

看完了？说点什么呢

[Go] 我在工作中总结的 Golang 高性能编程（下）

benjamin — Tue, 04 Mar 2025 09:47:33 GMT

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://benlifec.com/posts/golang/gohp_n

退出协程避免协程泄漏

协程泄漏原因一：超时控制

超时控制在网络编程中是非常常见的，利用 context.WithTimeout 和 time.After 都能够很轻易地实现。下面代码是一个典型的实现超时的例子。

下面代码的问题是，done 是一个无缓冲 channel , 当走到超时逻辑的时候，timeout 函数退出，done 没有了接收方，导致 doBadthing 函数在发送的时候会一直阻塞。无法退出 goroutine。

func doBadthing(done chan bool) {
    time.Sleep(time.Second)
    done <- true
}

func timeout(f func(chan bool)) error {
    done := make(chan bool)
    go f(done)
    select {
    case <-done:
        fmt.Println("done")
        return nil
    case <-time.After(time.Millisecond):
        return fmt.Errorf("timeout")
    }
}

怎么解决呢？

第一种方法，创建有缓冲区的 channel, 缓冲区设置为 1，即使没有接收方，发送方也不会发生阻塞。

第二种方法，使用 select + defalt 尝试发送，如果发送失败，则说明缺少接收者(receiver)，即超时了，那么走 default 逻辑直接退出即可。

func doGoodthing(done chan bool) {
    time.Sleep(time.Second)
    select {
    case done <- true:
    default:
        return
    }
}

实际的业务中更为复杂，我们会将任务拆分为好几段，这种情况下，就只能够使用 select，而不能够设置缓冲区的方式了。

协程泄漏原因二：channel 未关闭

func do(taskCh chan int) {
    for {
        select {
        case t := <-taskCh:
            time.Sleep(time.Millisecond)
            fmt.Printf("task %d is done\n", t)
        }
    }
}

func sendTasks() {
    taskCh := make(chan int, 10)
    go do(taskCh)
    for i := 0; i < 1000; i++ {
        taskCh <- i
    }
}

sendTasks 中启动了一个子协程 go do(taskCh)，因为这个协程一直处于阻塞状态，等待接收任务，因此直到程序结束, 协程也没有释放

解决办法：

任务发送结束之后，使用 close(taskCh) 将 channel taskCh 关闭
t, beforeClosed := <-taskCh 判断 channel 是否已经关闭, 如果关闭，退出协程

func doCheckClose(taskCh chan int) {
    for {
        select {
        case t, beforeClosed := <-taskCh:
            if !beforeClosed {
                fmt.Println("taskCh has been closed")
                return
            }
            time.Sleep(time.Millisecond)
            fmt.Printf("task %d is done\n", t)
        }
    }
}

func sendTasksCheckClose() {
    taskCh := make(chan int, 10)
    go doCheckClose(taskCh)
    for i := 0; i < 1000; i++ {
        taskCh <- i
    }
    close(taskCh)
}

这里提一嘴，关闭 chanel 的时候，可以使用 sync.Once 或互斥锁(sync.Mutex)确保 channel 只被关闭一次

type MyChannel struct {
    C    chan T
    once sync.Once
}

func NewMyChannel() *MyChannel {
    return &MyChannel{C: make(chan T)}
}

func (mc *MyChannel) SafeClose() {
    mc.once.Do(func() {
        close(mc.C)
    })
}

还有一种粗暴，但不推荐的关闭方式，可以无限关闭，但是有通过 recover 使程序恢复正常。

func SafeClose(ch chan T) (justClosed bool) {
    defer func() {
        if recover() != nil {
            // 一个函数的返回结果可以在defer调用中修改。
            justClosed = false
        }
    }()

    // 假设ch != nil。
    close(ch)   // 如果 ch 已关闭，将 panic
    return true // <=> justClosed = true; return
}

控制协程的并发数量

为什么要控制协程的并发数量，简单来说就是系统资源有限，每个协程至少需要消耗 2KB 的空间，那么假设计算机的内存是 2GB，那么至多允许 2GB/2KB = 1M 个协程同时存在。当然不止是内存有限，文件句柄，栈资源也是有限的，系统资源奔溃的时候，会出现以下但不限于的下面的错误信息。

// too many open files
// out of memory
// panic: too many concurrent operations on a single file or socket (max 1048575)

怎么控制：

方式一：利用缓冲区 channel 实现

// main_chan.go
func main() {
    var wg sync.WaitGroup
    ch := make(chan struct{}, 3)
    for i := 0; i < 10; i++ {
        ch <- struct{}{}
        wg.Add(1)
        go func(i int) {
            defer wg.Done()
            log.Println(i)
            time.Sleep(time.Second)
            <-ch
        }(i)
    }
    wg.Wait()
}

方式二： 利用第三方库

ants
tunny

方式三：如果控制了，但还是资源不足，可以使用 ulimit 来调整系统参数，比如： ulimit -n 999999，将同时打开的文件句柄数量调整为 999999 来解决这个问题，其他的参数也可以按需调整

sync.Pool

为什需要 Pool, 考虑下面的场景，json 的反序列化在文本解析和网络通信过程中非常常见，当程序并发度非常高的情况下，短时间内需要创建大量的临时对象。而这些对象是都是分配在堆上的，会给 GC 造成很大压力，严重影响程序的性能

Pool 可以保存和复用临时对象，减少内存分配，降低 GC 压力

Put 归还操作的时候，记得将值进行重置，不然下一次的 Get 操作，还会得到未进行重置的值

var studentPool = sync.Pool{
    New: func() interface{} { 
        return new(Student) 
    },
}

stu := studentPool.Get().(*Student)
json.Unmarshal(buf, stu)
studentPool.Put(stu)

sync.Once

sync.Once 是 Go 标准库提供的使函数只执行一次的实现，常应用于单例模式，和 init 有什么区别呢？

sync.Once 可以在代码的任意位置初始化和调用，因此可以延迟到使用时再执行，并发场景下是线程安全的, 而 init 函数是当所在的 package 首次被加载时执行，若迟迟未被使用，则既浪费了内存，又延长了程序加载时间。

sync.Cond

sync.Cond 经常用在多个 goroutine 等待，一个 goroutine 通知（事件发生）的场景。如果是一个通知，一个等待，使用互斥锁或 channel就能搞定了。

下面是一个简单的例子，三个协程调用 Wait() 等待，另一个协程调用 Broadcast() 唤醒所有等待的协程

var done = false

func read(name string, c *sync.Cond) {
    c.L.Lock()
    for !done {
        c.Wait()
    }
    log.Println(name, "starts reading")
    c.L.Unlock()
}

func write(name string, c *sync.Cond) {
    log.Println(name, "starts writing")
    time.Sleep(time.Second)
    c.L.Lock()
    done = true
    c.L.Unlock()
    log.Println(name, "wakes all")
    c.Broadcast()
}

func main() {
    cond := sync.NewCond(&sync.Mutex{})

    go read("reader1", cond)
    go read("reader2", cond)
    go read("reader3", cond)
    write("writer", cond)

    time.Sleep(time.Second * 3)
}

编译优化

如何减少 go 程序编译后的体积, 观察下面的 build 代码。

go build -ldflags="-s -w" -o server main.go

-s 忽略符号表和调试信息

-w 忽略DWARFv3调试信息，使用该选项后将无法使用gdb进行调试

逃逸分析

在 C 语言中，可以使用 malloc 和 free 手动在堆上分配和回收内存。Go 语言中，堆内存是通过垃圾回收机制自动管理的，无需开发者指定。那么，Go 编译器怎么知道某个变量需要分配在栈上，还是堆上呢？编译器决定内存分配位置的方式，就称之为逃逸分析(escape analysis)。逃逸分析由编译器完成，作用于编译阶段。

什么情况会逃逸？

情况一：指针逃逸

指针逃逸应该是最容易理解的一种情况了，即在函数中创建了一个对象，返回了这个对象的指针。这种情况下，函数虽然退出了，但是因为指针的存在，对象的内存不能随着函数结束而回收，因此只能分配在堆上。

// main_pointer.go
package main

import "fmt"

type Demo struct {
    name string
}

func createDemo(name string) *Demo {
    d := new(Demo) // 局部变量 d 逃逸到堆
    d.name = name
    return d
}

func main() {
    demo := createDemo("demo")
    fmt.Println(demo)
}

情况二：interface{} 动态类型逃逸

在 Go 语言中，空接口即 interface{} 可以表示任意的类型，如果函数参数为 interface{}，编译期间很难确定其参数的具体类型，也会发生逃逸。

情况二：栈空间不足

操作系统对内核线程使用的栈空间是有大小限制的，64 位系统上通常是 8 MB。可以使用 ulimit -a 命令查看机器上栈允许占用的内存的大小。

对 Go 编译器而言，超过一定大小的局部变量将逃逸到堆上, 比如切片占用内存超过一定大小，或无法确定当前切片长度时，对象占用内存将在堆上分配

情况三：闭包

Increase() 返回值是一个闭包函数，该闭包函数访问了外部变量 n，那变量 n 将会一直存在，直到 in 被销毁。很显然，变量 n 占用的内存不能随着函数 Increase() 的退出而回收，因此将会逃逸到堆上。

func Increase() func() int {
    n := 0
    return func() int {
        n++
        return n
    }
}

func main() {
    in := Increase()
    fmt.Println(in()) // 1
    fmt.Println(in()) // 2
}

那么如何利用逃逸分析提升性能呢？

一般情况下，对于需要修改原对象值，或占用内存比较大的结构体，选择传指针。对于只读的占用内存较小的结构体，直接传值能够获得更好的性能。虽然传指针可以减少值的拷贝，但是会导致内存分配逃逸到堆中，增加垃圾回收(GC)的负担。在对象频繁创建和删除的场景下，传递指针导致的 GC 开销可能会严重影响性能。

总结源自：极客兔兔，以及结合了自己在工作当中的实战经验。

看完了？说点什么呢

[Go] 我在工作中总结的 Golang 高性能编程（上）

benjamin — Tue, 04 Mar 2025 09:44:23 GMT

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://benlifec.com/posts/golang/gohp_p

struct{}

空结构体 struct{} 实例不占据任何的内存空间, 可以使用 unsafe.Sizeof 计算出一个数据类型实例需要占用的字节数，因为空结构体不占据内存空间，因此被广泛作为各种场景下的占位符使用。

有时候使用 channel 不需要发送任何的数据，只用来通知子协程执行/退出任务，或只用来控制协程并发度，这种情况下，声明为空结构体类型的 channel 是合适的。

第一种 struct{} 场景：通知子协程执行任务：

func worker(ch chan struct{}) {
    <-ch
    fmt.Println("do something")
    close(ch)
}

func main() {
    ch := make(chan struct{})
    go worker(ch)
    ch <- struct{}{}
}

第二种 struct{} 场景：结构体只包含方法，不包含任何的字段。例如上面例子中的 Door，在这种情况下，声明为空结构体是最合适的。

type Door struct{}

func (d Door) Open() {
    fmt.Println("Open the door")
}

func (d Door) Close() {
    fmt.Println("Close the door")
}

第三种 struct{} 场景：map 作为集合(Set)使用时，可以将值类型定义为空结构体，仅作为占位符使用即可, 这样做可以节省内存。

type Set map[string]struct{}

func (s Set) Has(key string) bool {
    _, ok := s[key]
    return ok
}

func (s Set) Add(key string) {
    s[key] = struct{}{}
}

func (s Set) Delete(key string) {
    delete(s, key)
}

func main() {
    s := make(Set)
    s.Add("Tom")
    s.Add("Sam")
    fmt.Println(s.Has("Tom"))
    fmt.Println(s.Has("Jack"))
}

strings.Builder

在 Go 语言中，拼接字符串事实上是创建了一个新的字符串对象。如果代码中存在大量的字符串拼接，对性能会产生严重的影响。

结论：不建议直接使用 + 和 fmt.Sprintf 做字符串拼接，在基准测试中，生成了一个长度为 10 的字符串，并拼接 1w 次，使用 + 和 fmt.Sprintf 的效率是最低的，和其余的方式(strings.Builder, []byte , bytes.Buffer )相比，性能相差约 1000 倍，而且消耗了超过 1000 倍的内存。

建议直接使用 strings.Builder 拼接字符串

func builderConcat (n int, str string) string {
  var builder strings.Builder

  builder.Grow(n * len(str))

  for i := n; i < n; i++ {
    builder.WriteString(str)
  }

  return builder.String()
}

对于 []byte 和 bytes.Buffer 来说 , strings.Builder 省去了 []byte 和字符串(string) 之间的转换, 直接将底层的 []byte 转换成了字符串类型返回了回来。

// 直接将底层的 []byte 转换成了字符串类型返回
func (b *Builder) String() string {
    return *(*string)(unsafe.Pointer(&b.buf))
}

[] bytes 拼接

func byteConcat(n int, str string) string {
    buf := make([]byte, 0)
    for i := 0; i < n; i++ {
        buf = append(buf, str...)
    }
    return string(buf)
}

bytes.Buffer 拼接

func bufferConcat(n int, s string) string {
    buf := new(bytes.Buffer)
    for i := 0; i < n; i++ {
        buf.WriteString(s)
    }
    return buf.String()
}

slice

先聊聊数组，在 C 语言中，数组变量是指向第一个元素的指针，但是 Go 语言中并不是。Go 语言中，数组变量属于值类型(value type)，因此当一个数组变量被赋值或者传递时，实际上会复制整个数组。例如，将 a 赋值给 b，修改 a 中的元素并不会改变 b 中的元素, 通常为了避免复制数组，一般会传递指向数组的指针。

a := [...]int{1, 2, 3} // ... 会自动计算数组长度
b := a
a[0] = 100
fmt.Println(a, b) // [100 2 3] [1 2 3]

slice 的性能陷阱

大量内存得不到释放，由于在已有切片的基础上进行切片，不会创建新的底层数组。因为原来的底层数组没有发生变化，内存会一直占用，直到没有变量引用该数组。因此很可能出现这么一种情况，原切片由大量的元素构成，但是我们在原切片的基础上切片，虽然只使用了很小一段，但底层数组在内存中仍然占据了大量空间，得不到释放。比较推荐的做法，使用 copy 替代 re-slice。

// good
// 通过 copy，指向了一个新的底层数组，当 origin 不再被引用后，内存会被垃圾回收(garbage collector, GC)。
func lastNumsByCopy(origin []int) []int {
    result := make([]int, 2)
    copy(result, origin[len(origin)-2:])
    return result
}

// bad
func lastNumsBySlice(origin []int) []int {
    return origin[len(origin)-2:]
}

下面是常用的 slice CURD 操作:

slice copy

将 a slice 完整的 copy 到 b slice 下面三种方法都可以：

b = make([]T, len(a))
copy(b, a)

b = append([]T(nil), a...)

b = append(a[:0:0], a...)

slice append

切片有三个属性，指针(ptr)、长度(len) 和容量(cap)。append 时有两种场景：

当 append 之后的长度小于等于 cap，将会直接利用原底层数组剩余的空间
当 append 后的长度大于 cap 时，则会分配一块更大的区域来容纳新的底层数组

因此，为了避免内存发生拷贝，如果能够知道最终的切片的大小，预先设置 cap 的值能够获得最好的性能

a = append(a, b...)

slice delete

切片的底层是数组，因此删除意味着后面的元素需要逐个向前移位。每次删除的复杂度为 O(N)，因此切片不合适大量随机删除的场景，这种场景下适合使用链表。

a = append(a[:i], a[i+1:]...)

a = [:i + copy(a[i:], a[i+1:])]

下面这种方式,删除指定元素后，将空余的位置置空，有助于垃圾回收(GC)
copy(a[i:], a[i+1:])

a[len(a) - 1] = nil
a = a[:len(a) -1]

slice insert

insert 和 append 类似。即在某个位置添加一个元素后，将该位置后面的元素再 append 回去。复杂度为 O(N)。因此，不适合大量随机插入的场景，这种场景下适合使用链表。

a = append(a[:i], append([]T{x}, a[i:]....)...)

slice filter

当原切片不会再被使用时，就地 filter 方式是比较推荐的，可以节省内存空间

n := 0

for _, x := range a {
  if keep(a) {
    a[n] = x
    n++
  }
}

a = a[:n]

slice push

在末尾追加元素，不考虑内存拷贝的情况，复杂度为 O(1)
在头部追加元素，时间和空间复杂度均为 O(N)，不推荐
```
// 尾部追加
a = append(a, x)
```

// 头部追加
a = append([]T{x}, a...)

slice pop

尾部删除元素，复杂度 O(1)
头部删除元素，如果使用切片方式，复杂度为O(1)。但是需要注意的是，底层数组没有发生改变，第 0 个位置的内存仍旧没有释放。如果有大量这样的操作，头部的内存会一直被占用

// 尾部删除
x, a := a[len(a) - 1], a[:len(a) - 1]

// 头部删除
x, a := a[0], a[1:]

for | for range

for range 在迭代过程中返回的是迭代值的拷贝
如果每次迭代的元素的内存占用很低(例如：[]int)，那么 for 和 range 的性能几乎是一样
如果 for range 迭代的元素是一个包含很多属性的 struct 结构体，那么 for 的性能将显著地高于 range，有时候甚至会有上千倍的性能差异
如果想使用 range 同时迭代下标和值，则需要将切片/数组的元素改为指针，才能不影响性能

reflect

尽量避免使用 reflect, 如果有替代方案情况下，比如我们要对结构体进行序列化和反序列化可以替换 go 标准库的 json 为 easyjson
FieldByName 相比于 Field 有一个数量级的性能劣化，在实际的应用中，就要避免直接调用 FieldByName。我们可以利用字典将 Name 和 Index 的映射缓存起来(map)，通过 Field 和 Index 来进行查找
Field 按照下标访问查询效率为 O(1)， FieldByName 按照 Name 访问，则需要遍历所有字段，查询效率为 O(N)。结构体所包含的字段(包括方法)越多，那么两者之间的效率差距则越大。

总结源自：极客兔兔，以及结合了自己在工作当中的实战经验

看完了？说点什么呢

[Go] Golang(1.23.2) 源码走读 - Mutex | RWMutex

benjamin — Fri, 28 Feb 2025 12:15:06 GMT

该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://benlifec.com/posts/golang/gosource_code_mutex

Mutex

下面是Mutex 结构体和位运算常量定义：

state: 32 位整数，高 29 位存储阻塞的队列（最高 2^29-1）, 最后一位（32为）存储 mutexLocked （是否上锁），倒数第二位存储 mutexWoken （协调唤醒操作，防止重复唤醒），倒数第三位存储 mutexStarving （是否处于饥饿模式）
sema: 通过 runtime 方法 runtime_SemacquireMutex 来阻塞/唤醒 goroutine 的信号量

const (
    mutexLocked = 1 << iota // mutex is locked // 1
    mutexWoken  // 2   
    mutexStarving  // 4 
    mutexWaiterShift = iota // 3  位运算计算队列等待数，要右移、左移的位数
    starvationThresholdNs = 1e6   // 饥饿模式等待阈值为 1ms
)

type Mutex struct {
    state int32
    sema  uint32
}

Lock

下面是 Lock 流程：

CAS 抢锁成功返回
抢锁失败，则进入 lockSlow 流程

func (m *Mutex) Lock() {
    // Fast path: grab unlocked mutex.
    if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
        return
    }
    // Slow path (outlined so that the fast path can be inlined)
    m.lockSlow()
}

下面是 lockSlow 流程：

如果锁已被占用并且锁不为饥饿模式并且满足自旋条件（runtime_canSpin 方法），进入自旋处理环节
在自旋处理环节中，如果当前锁有尚未唤醒的阻塞协程，则通过 CAS 操作将 state 的 mutexWoken 标识置为 1，将局部变量 awoke 置为 true
调用 runtime_doSpin 告知调度器 P 当前处于自旋模式
更新自旋次数 iter 和锁状态值 old
continue

func (m *Mutex) lockSlow() {
    var waitStartTime int64 // 标识当前 goroutine 在抢锁过程中的等待时长，单位：ns；
    starving := false // 标识当前是否处于饥饿模式
    awoke := false  // 标记当前 goroutine 是否从阻塞中被唤醒
    iter := 0 //标识当前 goroutine 参与自旋的次数 runtime_canSpin 判断是否已经达到 go 运行时最大的自旋次数
    old := m.state // 当前状态
    for {
        // Don't spin in starvation mode, ownership is handed off to waiters
        // so we won't be able to acquire the mutex anyway.
        if old&(mutexLocked|mutexStarving) == mutexLocked && runtime_canSpin(iter) {
            // Active spinning makes sense.
            // Try to set mutexWoken flag to inform Unlock
            // to not wake other blocked goroutines.
            if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
                atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
                awoke = true
            }
            runtime_doSpin()
            iter++
            old = m.state
            continue
        }

新值 new 中置为已加锁，即尝试抢锁
旧值为已被其他 goroutine 加锁或者处于锁已经饥饿模式，可以直接令新值的阻塞协程数加1
当前为饥饿模式且旧值已加锁，则将新值置为饥饿模式
如果是唤醒后的 goroutine，将该 mutexWoken 标识更新置 0

        new := old
        // Don't try to acquire starving mutex, new arriving goroutines must queue.
        if old&mutexStarving == 0 {
            new |= mutexLocked
        }
        if old&(mutexLocked|mutexStarving) != 0 {
            new += 1 << mutexWaiterShift
        }
        // The current goroutine switches mutex to starvation mode.
        // But if the mutex is currently unlocked, don't do the switch.
        // Unlock expects that starving mutex has waiters, which will not
        // be true in this case.
        if starving && old&mutexLocked != 0 {
            new |= mutexStarving
        }
        if awoke {
            // The goroutine has been woken from sleep,
            // so we need to reset the flag in either case.
            if new&mutexWoken == 0 {
                throw("sync: inconsistent mutex state")
            }
            new &^= mutexWoken
        }

旧值是未加锁状态且为不为饥饿模式，说明加锁成功，返回即可
旧值中锁未释放或者处于饥饿模式，则当前 goroutine 需要进入阻塞队列挂起
queueLifo 标识当前 goroutine 是从阻塞队列被唤起的老 goroutine 还是新进流程的 goroutine

        if atomic.CompareAndSwapInt32(&m.state, old, new) {
            if old&(mutexLocked|mutexStarving) == 0 {
                break // locked the mutex with CAS
            }
            // If we were already waiting before, queue at the front of the queue.
            queueLifo := waitStartTime != 0
            if waitStartTime == 0 {
                waitStartTime = runtime_nanotime()
            }
            runtime_SemacquireMutex(&m.sema, queueLifo, 1

下面是从阻塞态被唤醒的 goroutine 流程

当前 goroutine 进入阻塞队列时间长达 1 ms，则置为饥饿模式
此时锁是饥饿模式，则当前 goroutine 无需竞争可以直接获得锁(Unlock 流程，发现是饥饿模式，会直接唤醒队头的 goroutine)

            starving = starving || runtime_nanotime()-waitStartTime > starvationThresholdNs
            old = m.state
            if old&mutexStarving != 0 {
                // If this goroutine was woken and mutex is in starvation mode,
                // ownership was handed off to us but mutex is in somewhat
                // inconsistent state: mutexLocked is not set and we are still
                // accounted as waiter. Fix that.
                if old&(mutexLocked|mutexWoken) != 0 || old>>mutexWaiterShift == 0 {
                    throw("sync: inconsistent mutex state")
                }
                delta := int32(mutexLocked - 1<>mutexWaiterShift == 1 {
                    // Exit starvation mode.
                    // Critical to do it here and consider wait time.
                    // Starvation mode is so inefficient, that two goroutines
                    // can go lock-step infinitely once they switch mutex
                    // to starvation mode.
                    delta -= mutexStarving
                }
                atomic.AddInt32(&m.state, delta)
                break
            }
            awoke = true
            iter = 0
        } else {
            old = m.state
        }

Unlock

下面是 Unlock 流程:

通过原子操作解锁；
倘若解锁时发现，目前参与竞争的仅有自身一个 goroutine，则直接返回即可；
倘若发现锁中还有阻塞协程，则走入 unlockSlow 分支.

func (m *Mutex) Unlock() {
    new := atomic.AddInt32(&m.state, -mutexLocked)
    if new != 0 {
        m.unlockSlow(new)
    }
}

解锁时，如果是非饥饿模式

倘若阻塞队列内无 goroutine 或者 mutexLocked、mutexStarving、mutexWoken 标识位任一不为零，退出流程
基于 CAS 操作将 Mutex.state 中的阻塞协程数减 1，倘若成功，则唤起阻塞队列头部的 goroutine，并退出
倘若减少阻塞协程数的 CAS 操作失败，则更新此时的 Mutex.state 为新的 old 值，开启下一轮循环

func (m *Mutex) unlockSlow(new int32) {
    if (new+mutexLocked)&mutexLocked == 0 {
        fatal("sync: unlock of unlocked mutex")
    }
    if new&mutexStarving == 0 {
        old := new
        for {
            // If there are no waiters or a goroutine has already
            // been woken or grabbed the lock, no need to wake anyone.
            // In starvation mode ownership is directly handed off from unlocking
            // goroutine to the next waiter. We are not part of this chain,
            // since we did not observe mutexStarving when we unlocked the mutex above.
            // So get off the way.
            if old>>mutexWaiterShift == 0 || old&(mutexLocked|mutexWoken|mutexStarving) != 0 {
                return
            }
            // Grab the right to wake someone.
            new = (old - 1<

如果是饥饿模式解锁

直接唤醒阻塞队列头部的 goroutine 即可, 其余进来抢锁的 goroutine，发现是饥饿模式，都会被排到队列的队尾。

func (m *Mutex) unlockSlow(new int32) {
    if new&mutexStarving == 0 {
    } else {
        runtime_Semrelease(&m.sema, true, 1)
    }
}

`RWMutex`

下面是 RWMutex 结构体

rwmutexMaxReaders：共享读锁的 goroutine 数量上限，值为 2^29
w：RWMutex 内置的互斥锁 sync.Mutex
writerSem：写锁阻塞队列的信号量
readerSem：读锁阻塞队列的信号量
readerCount：无写锁情况下等于占用或等待读锁的 goroutine 数量，存在写锁流程时，该值一般为负数，实际值为读锁流程的 goroutine 数量减 rwmutexMaxReaders（2^29）.
readerWait：当前 goroutine 获取写锁前，还需要等待多少个 goroutine 释放读锁

type RWMutex struct {
    w           Mutex        // held if there are pending writers
    writerSem   uint32       // semaphore for writers to wait for completing readers
    readerSem   uint32       // semaphore for readers to wait for completing writers
    readerCount atomic.Int32 // number of pending readers
    readerWait  atomic.Int32 // number of departing readers
}

const rwmutexMaxReaders = 1 << 30

`RLock`

下面是 RLock 流程:

基于原子操作，将 RWMutex 的 readCount 变量加一，表示占用或等待读锁的 goroutine 数加一
若 RWMutex.readCount 的新值仍小于 0，说明有 goroutine 未释放写锁，因此将当前 goroutine 添加到读锁的阻塞队列中并阻塞挂起

func (rw *RWMutex) RLock() {
    if rw.readerCount.Add(1) < 0 {
        // A writer is pending, wait for it.
        runtime_SemacquireRWMutexR(&rw.readerSem, false, 0)
    }
}

`RUnlock`

下面是 RUnLock 流程:

基于原子操作，将 RWMutex 的 readCount 变量加一，表示占用或等待读锁的 goroutine 数减一
readCount 的新值小于 0，说明有 goroutine 在等待获取写锁，则走入 RWMutex.rUnlockSlow 的流程中.

func (rw *RWMutex) RUnlock() {
    if r := atomic.AddInt32(&rw.readerCount, -1); r < 0 {
        rw.rUnlockSlow(r)
    }
}

`Lock`

下面是 Lock 流程:

对 RWMutex 内置的互斥锁进行加锁操作；
基于原子操作，对 RWMutex.readerCount 进行减少 -rwmutexMaxReaders 的操作, 目的是阻塞即将获取写锁的 goroutine
倘若此时存在未释放读锁的 gouroutine（r != 0），将当前 goroutine 添加到写锁的阻塞队列中挂起

func (rw *RWMutex) Lock() {
    rw.w.Lock()
    r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
    if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0 {
        runtime_SemacquireMutex(&rw.writerSem, false, 0)
    }
}

`UnLock`

下面是 UnLock 流程: go func (rw *RWMutex) Unlock() { r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders) if r >= rwmutexMaxReaders { fatal("sync: Unlock of unlocked RWMutex") } for i := 0; i < int(r); i++ { runtime_Semrelease(&rw.readerSem, false, 0) } rw.w.Unlock() }

基于原子操作，将 RWMutex.readerCount 的值加上 rwmutexMaxReaders
唤醒读锁阻塞队列中的所有 goroutine
解开 RWMutex 内置的互斥锁

看完了？说点什么呢



[Go] Golang(1.23.2) 源码走读 - Context
benjamin — Tue, 25 Feb 2025 01:32:17 GMT
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://benlifec.com/posts/golang/gosource_context
Context
context 数据结构
type Context interface {
    Deadline() (deadline time.Time, ok bool) // 返回 context 的过期时间
    Done() <-chan struct{}                   // 返回 context 中的 channel
    Err() error                              // 返回错误
    Value(key any) any                       // 返回 context 中的对应 key 的值
}
context.Background | context.TODO
我们常用的 context.Background() 和 context.TODO() 方法返回的均是 emptyCtx 类型的一个实例
var (
    background = new(emptyCtx)
    todo       = new(emptyCtx)
)

func Background() Context {
    return background
}

func TODO() Context {
    return todo
}
emptyCtx
emptyCtx 对 Context 接口实现如下，emptyCtx 本质上类型为一个整型。我们观察其实现，发现 emptyCtx 没有 实现 Context 的高级功能，像 cancel | timeout
Done 方法返回一个 nil channel，写入或者读取数据，均会陷入阻塞
Err 方法返回的错误永远为 nil
Value 方法返回的 value 同样永远为 nil
Deadline 标识当前 context 不存在过期时间
type emptyCtx int

func (*emptyCtx) Deadline() (deadline time.Time, ok bool) {
    return
}

func (*emptyCtx) Done() <-chan struct{} {
    return nil
}

func (*emptyCtx) Err() error {
    return nil
}

func (*emptyCtx) Value(key any) any {
    return
}
context.WithCancel
下面是 WithCancel 源码：
func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
    c := withCancel(parent)
    return c, func() { c.cancel(true, Canceled, nil) }
}

func withCancel(parent Context) *cancelCtx {
    if parent == nil {
        panic("cannot create context from nil parent")
    }
    c := &cancelCtx{}
    c.propagateCancel(parent, c)
    return c
}
校验父 context 非空
在 propagateCancel 方法 中构建父子 ctx, 保证父 context 终止时，该 cancelCtx 也会被终止
将 cancelCtx 返回，返回用以终止该 cancelCtx 的闭包函数
下面是 cancelCtx 结构体：
type cancelCtx struct {
    Context   
  mu       sync.Mutex
  done     atomic.Value             
  children map[canceler]struct{}
  err      error
  cause    error
}

// A canceler is a context type that can be canceled directly. The
// implementations are *cancelCtx and *timerCtx.
type canceler interface {
    cancel(removeFromParent bool, err, cause error)
    Done() <-chan struct{}
}
下面是 propagateCancel 方法：
// propagateCancel arranges for child to be canceled when parent is.
// It sets the parent context of cancelCtx.
func (c *cancelCtx) propagateCancel(parent Context, child canceler) {
    c.Context = parent

    done := parent.Done()
    if done == nil {
        return // parent is never canceled
    }

    select {
    case <-done:
        // parent is already canceled
        child.cancel(false, parent.Err(), Cause(parent))
        return
    default:
    }

    if p, ok := parentCancelCtx(parent); ok {
        // parent is a *cancelCtx, or derives from one.
        p.mu.Lock()
        if p.err != nil {
            // parent has already been canceled
            child.cancel(false, p.err, p.cause)
        } else {
            if p.children == nil {
                p.children = make(map[canceler]struct{})
            }
            p.children[child] = struct{}{}
        }
        p.mu.Unlock()
        return
    }

    if a, ok := parent.(afterFuncer); ok {
        // parent implements an AfterFunc method.
        c.mu.Lock()
        stop := a.AfterFunc(func() {
            child.cancel(false, parent.Err(), Cause(parent))
        })
        c.Context = stopCtx{
            Context: parent,
            stop:    stop,
        }
        c.mu.Unlock()
        return
    }

    goroutines.Add(1)
    go func() {
        select {
        case <-parent.Done():
            child.cancel(false, parent.Err(), Cause(parent))
        case <-child.Done():
        }
    }()
}
propagateCancel 方法中：
parent 是不会被 cancel 的类型（如 emptyCtx），则直接返回
parent 已经被 cancel，则直接终止子 context，并以 parent 的 err 作为子 context 的 err， parent 的 Cause 作为子 context 的 cause
parent 是 cancelCtx 的类型，加锁，并将子 context 添加到 parent 的 children map 当中，函数终止
parent 不是 cancelCtx 类型但实现了 afterFuncer 接口，加锁，以 child cancel 为参数传入父 context 的 AfterFunc 函数中，构建父子 context, 此时父 context 为 stopCtx
假如 parent 不是 cancelCtx 类型，但存在 cancel 的能力（用户自定义实现的 context），则启动一个协程，通过多路复用的方式监控 parent 状态，倘若其终止，则同时终止子 context，并透传 parent 的 err
下面是 propagateCancel 函数中的 parentCancelCtx 源码, 用来校验 parent 是否为 cancelCtx 的类型
func parentCancelCtx(parent Context) (*cancelCtx, bool) {
    done := parent.Done()
    if done == closedchan || done == nil {
        return nil, false
    }
    p, ok := parent.Value(&cancelCtxKey).(*cancelCtx)
    if !ok {
        return nil, false
    }
    pdone, _ := p.done.Load().(chan struct{})
    if pdone != done {
        return nil, false
    }
    return p, true
}
parent 的 channel 已关闭或者是不会被 cancel 的类型，则返回 false
以特定的 cancelCtxKey 从 parent 中取值，取得的 value 是 parent 本身，则返回 true（基于 cancelCtxKey 为 key 取值时返回 cancelCtx 自身，是 cancelCtx 特有的协议）
cancel
下面是 cancel 源码，当我们执行  withCancel 返回的 cancelFunc 时，会调用  func() { c.cancel(true, Canceled, nil) }
// cancel closes c.done, cancels each of c's children, and, if
// removeFromParent is true, removes c from its parent's children.
// cancel sets c.cause to cause if this is the first time c is canceled.
func (c *cancelCtx) cancel(removeFromParent bool, err, cause error) {
    if err == nil {
        panic("context: internal error: missing cancel error")
    }
    if cause == nil {
        cause = err
    }
    c.mu.Lock()
    if c.err != nil {
        c.mu.Unlock()
        return // already canceled
    }
    c.err = err
    c.cause = cause
    d, _ := c.done.Load().(chan struct{})
    if d == nil {
        c.done.Store(closedchan)
    } else {
        close(d)
    }
    for child := range c.children {
        // NOTE: acquiring the child's lock while holding parent's lock.
        child.cancel(false, err, cause)
    }
    c.children = nil
    c.mu.Unlock()

    if removeFromParent {
        removeChild(c.Context, c)
    }
}
进入方法主体，首先校验传入的 err 是否为空，若为空则 panic
加锁
校验 cancelCtx 自带的 err 是否已经非空，若非空说明已被 cancel，则解锁返回
将传入的 err 赋给 cancelCtx.err
处理 cancelCtx 的 channel，若 channel 此前未初始化，则直接注入一个 closedChan，否则关闭该 channel
遍历当前 cancelCtx 的 children set，依次将 children context 都进行 cancel
解锁
根据传入的 removeFromParent flag 判断是否需要手动把 cancelCtx 从 parent 的 children set 中移除
context.WithTimout | context.WithDeadline
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {
    return WithDeadline(parent, time.Now().Add(timeout))
}
WithTimeout 本质上会调用 context.WithDeadline 方法
func WithDeadlineCause(parent Context, d time.Time, cause error) (Context, CancelFunc) {
    if parent == nil {
        panic("cannot create context from nil parent")
    }
    if cur, ok := parent.Deadline(); ok && cur.Before(d) {
        // The current deadline is already sooner than the new one.
        return WithCancel(parent)
    }
    c := &timerCtx{
        deadline: d,
    }
    c.cancelCtx.propagateCancel(parent, c)
    dur := time.Until(d)
    if dur <= 0 {
        c.cancel(true, DeadlineExceeded, cause) // deadline has already passed
        return c, func() { c.cancel(false, Canceled, nil) }
    }
    c.mu.Lock()
    defer c.mu.Unlock()
    if c.err == nil {
        c.timer = time.AfterFunc(dur, func() {
            c.cancel(true, DeadlineExceeded, cause)
        })
    }
    return c, func() { c.cancel(true, Canceled, nil) }
}
校验 parent context 非空
校验 parent 的过期时间是否早于自己，若是，则构造一个 cancelCtx 返回即可（此时在给子 ctx 包装 timeCtx, 没意义，因为一旦父 context 退出，子 context 也会被cancel）
构造出一个新的 timerCtx
propagateCancel 构建父子 ctx
判断过期时间是否已到，若是，直接 cancel timerCtx，并返回 DeadlineExceeded ("context deadline exceeded") 错误
加锁
启动 time.Timer，设定一个延时时间，即达到过期时间后会终止该 timerCtx，并返回 DeadlineExceeded 的错误
解锁
返回 timerCtx，和一个封装了 cancel 逻辑的函数
下面是 timerCtx 源码：
// A timerCtx carries a timer and a deadline. It embeds a cancelCtx to
// implement Done and Err. It implements cancel by stopping its timer then
// delegating to cancelCtx.cancel.
type timerCtx struct {
    cancelCtx
    timer *time.Timer // Under cancelCtx.mu.

    deadline time.Time
}
复用了 cancelCtx 的能力,  并且加入了定时器，可以等时间到了再去 cancel
context.WithValue
func WithValue(parent Context, key, val any) Context {
    if parent == nil {
        panic("cannot create context from nil parent")
    }
    if key == nil {
        panic("nil key")
    }
    if !reflectlite.TypeOf(key).Comparable() {
        panic("key is not comparable")
    }
    return &valueCtx{parent, key, val}
}
parent context 为空，panic
key 为空 panic
key 的类型不可比较，panic
parent context 以及 kv对，返回一个新的 valueCtx
valueCtx.Value
func (c *valueCtx) Value(key any) any {
    if c.key == key {
        return c.val
    }
    return value(c.Context, key)
}

func value(c Context, key any) any {
    for {
        switch ctx := c.(type) {
        case *valueCtx:
            if key == ctx.key {
                return ctx.val
            }
            c = ctx.Context
        case *cancelCtx:
            if key == &cancelCtxKey {
                return c
            }
            c = ctx.Context
        case withoutCancelCtx:
            if key == &cancelCtxKey {
                // This implements Cause(ctx) == nil
                // when ctx is created using WithoutCancel.
                return nil
            }
            c = ctx.c
        case *timerCtx:
            if key == &cancelCtxKey {
                return &ctx.cancelCtx
            }
            c = ctx.Context
        case backgroundCtx, todoCtx:
            return nil
        default:
            return c.Value(key)
        }
    }
}
Value 方法中，判断当前 valueCtx 的 key 是否等于用户传入的 key，是，则直接返回其 value。不是，调用 value 方法，从 parent context 中依次向上寻找
阅读源码可以看出，valueCtx 不适合视为存储介质，存放大量的 kv 数据：
一个 valueCtx 实例只能存一个 kv 对，因此 n 个 kv 对会嵌套 n 个 valueCtx，造成空间浪费；
基于 k 寻找 v 的过程是线性的，时间复杂度 O(N)；
看完了？说点什么呢


情绪的微光-2025版
benjamin — Thu, 20 Feb 2025 09:23:36 GMT
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://benlifec.com/notes/3
当心情低谷，来一碗能疗愈自己的“心灵鸡汤“ --（2025 版）
陈丹青为贾樟柯作序
陈丹青为贾樟柯作序写到的一段话，特意翻找到原文：
“ 我记得贾樟柯在一部电影的花絮中接受采访，他说，他在荒败的小县城混时，有很多机会沦落，变成坏孩子，毁了自己。这是诚实的自白。我在知青岁月中也有太多机会沦丧，破罐子破摔。刚才有年轻人问：“谁能救救我们？”我的回答可能会让年轻人不舒服：这是奴才的思维。永远不要等着谁来救我们。每个人应该自己救自己，从小救起来。什么叫做救自己呢？以我的理解，就是忠实自己的感觉，认真做每一件事，不要烦，不要放弃，不要敷衍。哪怕写文章时标点符号弄清楚，不要有错别字——这就是我所谓的自己救自己。我们都得一步一步救自己， 我靠的是一笔一笔地画画，贾樟柯靠的是一寸一寸的胶片。 ”
史铁生
“我四肢健全时，常抱怨周围环境糟糕，瘫痪后，怀念当初可以行走奔跑的日子。几年后长了褥疮，怀念起前两年安稳坐在轮椅上的时光；后来得了尿毒症，怀念当初长褥疮；又过了一些年，要透析，清醒的时间很少，怀念尿毒症的时候。”
查理·卓别林：当我真正开始爱自己
As I Began to Love Myself
当我真正开始爱自己
As I began to love myself I found that anguish and emotional suffering are only warning signs that I was living against my own truth. Today, I know, this is AUTHENTICITY.
当我真正开始爱自己，我才意识到，所有的痛苦和情感的折磨，仅仅是在提醒，我的生活背离了真实的自己。今日，我明白，这叫做「真实」。
As I began to love myself I understood how much it can offend somebody as I try to force my desires on this person, even though I knew the time was not right and the person was not ready for it, and even though this person was me. Today I call it RESPECT.
当我真正开始爱自己，我才懂得，当我将自己的意愿强加于人时，是多么的冒犯无礼，即使那时我知晓时机尚未成熟，那个人也并未做好准备，即便那个人就是我自己。今日我明白这叫做「尊重」。
As I began to love myself I stopped craving for a different life, and I could see that everything that surrounded me was inviting me to grow. Today I call it MATURITY.
当我开始真正爱自己，我不再苛求不一样的人生，我明白任何发生在我身边的事，都是对我成长的邀约。而今，我称之为「成熟」。
As I began to love myself I understood that at any circumstance, I am in the right place at the right time, and everything happens at the exactly right moment, so I could be calm. Today I call it SELF-CONFIDENCE.
当我开始真正爱自己，我才明白在任何情况下，我其实一直处于恰好的时机、恰好的地方，而每件事的发生也都恰如其分。由此，我得以平静。今日，我称其为「自信」。
As I began to love myself I quit stealing my own time, and I stopped designing huge projects for the future. Today, I only do what brings me joy and happiness, things I love to do and that make my heart cheer, and I do them in my own way and in my own rhythm. Today I call it SIMPLICITY.
当我开始真正爱自己，我不再挥霍自己生命和时间，不再去擘画波澜壮阔的未来。今天的我，只做能为我带来喜悦和幸福的事，做那些我所热爱，且能鼓舞我心的事情，用我特有的方式，按照我自己的节奏。今日我知晓这叫做「简单」。
As I began to love myself I freed myself of anything that is no good for my health – food, people, things, situations, and everything that drew me down and away from myself. At first I called this attitude a healthy egoism. Today I know it is LOVE OF ONESELF.
当我开始真正爱自己，我开始远离所有不健康的东西，不论是饮食、人物、事情亦或环境，远离拖累我、让我背离了真实自我的一切。从前的我称呼这为“有益健康的利己主义”。今天我知道，这其实是「自爱」。
As I began to love myself I quit trying to always be right, and ever since I was wrong less of the time. Today I discovered that is MODESTY.
当我开始真正爱自己，我不再总想做到永远正确，从那时起，我犯错的时候反而更少了。现在我发现那就是「谦逊」。
As I began to love myself I refused to go on living in the past and worry about the future. Now, I only live for the moment, where EVERYTHING is happening. Today I live each day, day by day, and I call it FULFILLMENT.
当我开始真正爱自己，我不再继续沉溺于过去，也不再为明天而忧虑。如今，我只活在这一切正在发生的当下。今天，我活在此时此地，如此日复一日，而我称这为「圆满」。
As I began to love myself I recognized that my mind can disturb me and it can make me sick. But As I connected it to my heart, my mind became a valuable ally. Today I call this connection WISDOM OF THE HEART.
当我真正开始爱自己，我明白，我的思虑扰乱了自我，使我变得了无生趣。但当我与本心相连，心灵的力量就成为了我坚实的后盾。今日我称这种连结为「心灵的智慧」。
We no longer need to fear arguments, confrontations or any kind of problems with ourselves or others. Even stars collide, and out of their crashing new worlds are born. Today I know THAT IS LIFE!
我们无需再害怕生命中的争论、冲突，或是任何出现在与我们自己或与其他人之间的问题。因为即使是星星也会有碰撞在一起的时候，而从它们的撞击中，新的世界将会诞生。今天我知道，这，就是「生命」！
看完了？说点什么呢


[Go] 我在工作中常用的 Golang 设计模式
benjamin — Thu, 20 Feb 2025 07:23:24 GMT
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://benlifec.com/posts/golang/godesignpattern
责任链模式
含义：  指定顺序串行化地执行一系列的任务，前置的任务节点根据执行情况可以选择提前熔断流程或者正常向下执行.
场景：  grpc 拦截器 和 gin 的中间件都是责任链模式
实现：
grpc 拦截器，责任链模式实现
原理：Interceptor 中的 handler 参数就指代的是下一个 Interceptor, 如果是最后一个 Interceptor， 那 handle 就是定义的 enhance hanlder。
type Handler func(ctx context.Context, req []string) ([]string, error)

type Interceptor func(ctx context.Context, req []string, handler Handler) ([]string, error)

func ChainInterceptors(interceptors []Interceptor) Interceptor {
    if len(interceptors) == 0 {
        return nil
    }

    return func(ctx context.Context, req []string, handler Handler) ([]string, error) {
        return interceptors[0](ctx, req, GetNextChainHandler(interceptors, 0, handler))
    }
}

func GetNextChainHandler(interceptors []Interceptor, index int, nextHandler Handler) Handler {

    if index == len(interceptors)-1 {
        return nextHandler
    }

    return func(ctx context.Context, req []string) ([]string, error) {
        return interceptors[index+1](ctx, req, nextHandler)
    }
}
下面是使用 grpc 拦截器的代码
// 用法
// enhanced final handler
var handler Handler = func(ctx context.Context, req []string) ([]string, error) {
    req = append(req, "enhance final handler")
    return req, nil
}

var interceptor1 Interceptor = func(ctx context.Context, req []string, handler Handler) ([]string, error) {
    fmt.Println("interceptor1 preprocess...")
    req = append(req, "interceptor1_preprocess")
    resp, err := handler(ctx, req)
    fmt.Println("interceptor1 postprocess")
    resp = append(resp, "interceptor1_postprocess")
    return resp, err
}

var interceptor2 Interceptor = func(ctx context.Context, req []string, handler Handler) ([]string, error) {
    fmt.Println("interceptor2 preprocess...")
    req = append(req, "interceptor2_preprocess")
    resp, err := handler(ctx, req)
    fmt.Println("interceptor2 postprocess")
    resp = append(resp, "interceptor2_postprocess")
    return resp, err
}

func main() {
    chainedInterceptor := ChainInterceptors([]Interceptor{
        interceptor1, interceptor2,
    })

    resp, _ := chainedInterceptor(context.Background(), nil, handler)
    fmt.Printf("resp: %+v", resp)
}
gin 中间件 责任链模式实现,  与 grpc 拦截器层层传递不同的是，gin 的中间件是由 gin 本身管理的，需要 .Next,  .Abort 去熔断或者终止。
package main

const MaxHandlersCnt = 100

type Handler func(ctx *Context, req map[string]interface{}) (map[string]interface{}, error)

type HandlerManager struct {
    index    int
    handlers []Handler
}

func NewHandlerManager(handlers ...Handler) *HandlerManager {
    return &HandlerManager{
        index:    -1,
        handlers: handlers,
    }
}

func (c *Context) Next(req map[string]interface{}) {
    c.index++
    for c.index < len(c.handlers) && c.index <= MaxHandlersCnt {
        c.handlers[c.index](c, req)
        c.index++
    }
}

func (c *Context) Abort() {
    c.index = MaxHandlersCnt
}
单例模式
含义： 结构体在整个进程中存在唯一的示例来供外部反复调用
场景：
只允许存在一个实例的类，比如全局统一的监控或者统计模块
实例化时很耗费资源的类，比如连接池、第三方库的客户端等
负责业务领域分层的类，比如 domain、service、repo 等
实现：
在单例模式的实现上，可以分为饿汉式和懒汉式两种类型：
• 饿汉式：应用一启动，就完成单例的初始化工作
• 懒汉式：手动执行单例的初始化工作
首先是饿汉模式

var s *singleton

type Singleton interface {
    Work()
}

type singleton struct{}

func init() {
    s = &singleton{}
}

func (s *singleton) Work() {
}

func GetSingletonIns() Singleton {
    return s
}
然后是懒汉模式
懒汉模式的第一种做法是锁 + double check.
package main

import "sync"

var (
    s   Singleton
    mux sync.Mutex
)

type Singleton interface {
    Work()
}

type singleton struct{}

func newSingleton() Singleton {
    return &singleton{}
}

func (s *singleton) Work() {
}

func GetSingletonIns() Singleton {
    if s != nil {
        return s
    }

    mux.Lock()

    defer mux.Unlock()

    // double check
    if s != nil {
        return s
    }

    s = newSingleton()

    return s

}
懒汉模式的第二种做法是使用 sync.Once, 原理也是锁 + double check, Once 结构体有一个 uint32 类型的 done 字段，表示 once 保护的函数是否已经被执行过。( 通过 atomic.StoreUint32(&o.done, 1) 对 done 字段进行原子操作的修改 )
package main

import "sync"

var (
    s    Singleton
    once sync.Once
)

type Singleton interface {
    Work()
}

type singleton struct{}

func newSingleton() Singleton {
    return &singleton{}
}

func (s *singleton) Work() {
}

func GetSingletonIns() Singleton {
    once.Do(func() {
        s = newSingleton()
    })

    return s
}
工厂模式
含义： 在类和使用方之间添加一个工厂类中间层，实现了代码的防腐和解耦
场景：
业务方法和类之间产生过高的耦合度
类的定义发生变更，代码中类的构造流程都需要改动
实现：
简单工厂模式: 工厂模式中最简单直观的实现方式，有很好的切面效果，但是类扩展时无法满足开闭原则
工厂方法模式: 一个类对应一个工厂类，工程类实现工厂接口, 存在代码冗余，但可以在类扩展时满足开闭原则
抽象工厂模式:  工厂方法模式针对的是同一类或同等级产品(美式，拿铁，卡布奇诺),而抽象工厂模式针对的是多种类的产品设计（星巴克的拿铁，瑞幸的拿铁...）
首先是是简单工厂：
工厂负责生成咖啡，入口是下面的 CoffeeMaker 函数。
package main

import "fmt"

type Coffee interface {
}

type americanoCoffee struct {
}

type latteCoffee struct {
}

type cappuccinoCoffee struct {
}

func NewAmericanoCoffee() Coffee {
    return &americanoCoffee{}
}

func NewLatteCoffee() Coffee {
    return &latteCoffee{}
}

func NewCappuccinoCoffee() Coffee {
    return &cappuccinoCoffee{}
}

type coffeeMaker func() Coffee

type CoffeeFactory struct {
    coffeeList map[string]coffeeMaker
}

func NewCoffeeFactory() *CoffeeFactory {
    return &CoffeeFactory{
        coffeeList: map[string]coffeeMaker{
            "americano":  NewAmericanoCoffee,
            "latte":      NewLatteCoffee,
            "cappuccino": NewCappuccinoCoffee,
        },
    }
}

// 工厂入口
func (f *CoffeeFactory) MakeCoffee(typ string) (Coffee, error) {
    coffeeMaker, ok := f.coffeeList[typ]

    if !ok {
        return nil, fmt.Errorf("coffee type %s is not exist", typ)
    }

    return coffeeMaker, nil
}
简单工厂有个问题，如果在加一种类型的咖啡，会直接修改 coffeeList, 不遵循开闭原则。 所以有个下面的工厂方法模式，每个具体的咖啡类后都有一个工厂类。这样做的好处是，以后再添加一种类型的咖啡，比如猫屎咖啡，只需要加猫屎咖啡类和其工厂类就可以了。
package main

type Coffee interface {
}

type CoffeeFactory interface {
    CreateCoffee() Coffee
}

type americanoCoffee struct {
}

// 美式咖啡的工厂类
type AmericanoFactory struct {
}


func NewAmericanoFactory() CoffeeFactory {
    return &AmericanoFactory{}
}

func (a *AmericanoFactory) CreateCoffee() Coffee {
    return americanoCoffee{}
}

type latteCoffee struct {
}

// 拿铁的工厂类
type LatteFactory struct {
}


func NewLatteFactory() CoffeeFactory {
    return &AmericanoFactory{}
}

func (a *LatteFactory) CreateCoffee() Coffee {
    return americanoCoffee{}
}

type cappuccinoCoffee struct {
}

// 卡布奇诺的工厂类
type CappuccinoFactory struct {
}

func NewCappuccinoFactory() CoffeeFactory {
    return &CappuccinoFactory{}
}

func (a *CappuccinoFactory) CreateCoffee() Coffee {
    return cappuccinoCoffee{}
}

func NewCapCoffee() Coffee {
    return &americanoCoffee{}
}

func NewLatteCoffee() Coffee {
    return &latteCoffee{}
}

func NewCappuccinoCoffee() Coffee {
    return &cappuccinoCoffee{}
}
工厂方法模式针对的是同一类或同等级产品(美式，拿铁，卡布奇诺只有一层咖啡的维度)，而抽象工厂模式针对的是多种类的产品设计（星巴克的拿铁，瑞幸的拿铁...）也就是增添了品牌方的维度。
美式咖啡 AmericanoCoffee，拿铁咖啡 LatteCoffee 是接口，创建拿铁和美式的工厂(CoffeeFactory)也是接口，不同品牌方（星巴克，瑞幸），对美式 (StarbucksAmericanoCoffee)，拿铁，以及他们的工厂接口(StarbucksCafeFactory)做实现。
package main

type CoffeeFactory interface {
    CreateAmericanoCoffee() AmericanoCoffee
    CreateLatteCoffee() LatteCoffee
}

type AmericanoCoffee interface{}

type LatteCoffee interface{}

// 星巴克美式
type StarbucksAmericanoCoffee struct {
}

func NewStarbucksAmericanoCoffee() AmericanoCoffee {
    return &StarbucksAmericanoCoffee{}
}

// 星巴克拿铁
type StarbucksLatteCoffee struct {
}

func NewStarbucksLatteCoffee() LatteCoffee {
    return &StarbucksLatteCoffee{}
}

// 星巴克品牌实现
type StarbucksCafeFactory struct{}

func (s *StarbucksCafeFactory) CreateAmericanoCoffee() AmericanoCoffee {
    return NewStarbucksAmericanoCoffee()
}

func (s *StarbucksCafeFactory) CreateLatteCoffee() LatteCoffee {
    return NewStarbucksLatteCoffee()
}
如果再加一个品牌方，只需要增加对美式和拿铁的接口实现(上面代码例子中的 StarbucksAmericanoCoffee, StarbucksLatteCoffee) 以及品牌方工厂实现(上面代码例子中的 StarbucksCafeFactory)。
装饰器模式
含义： 在不改变其原有的结构和功能为对象添加新功能的模式其实就叫做装饰器模式，装饰比继承更加灵活,可以实现装饰者和被装饰者之间松耦合
功能：功能之间耦合太深，并且该功能可能要随时新增或者撤销。
实现：
圆形和矩形都是形状(接口 Shape), 都可以实现画一个圆形/矩形的功能，在装饰器模式的基础上，在新增一个给圆形/矩形的边框画成绿色。如果不用装饰器，你可以直接在圆形/矩形的 Draw 方法里写该功能，但是耦合度高。要根据自己的业务需求来选择合适的模式。
package main

import "fmt"

type Shape interface {
    Draw()
}

type Circle struct {
}

func (c *Circle) Draw() {
    fmt.Println("绘制圆形")
}

type Rectangle struct {
}

func (c *Rectangle) Draw() {
    fmt.Println("绘制矩形")
}

// 装饰器声明
type DecoratorShape Shape

func NewColorfulShape(s Shape) DecoratorShape {
    return s
}

type RedColorFullShape struct {
    DecoratorShape
}

func NewRedColorFullShape(s DecoratorShape) DecoratorShape {
    return &RedColorFullShape{s}
}

func (r *RedColorFullShape) Draw() {
    r.DecoratorShape.Draw()
    fmt.Println("圆形/矩形边框画成了红色")
}
观察者模式
场景：
mq 发布订阅
etcd watcher 功能
在观察者模式中，核心的角色包含三类：
Observer：观察者.
Event：事物的变更事件. 其中 Topic 标识了事物的身份以及变更的类型，Val 是变更详情
EventBus：事件总线， 负责维护管理观察者，并且在事物发生变更时，将情况同步给每个观察者.
首先定义这三个角色：
type Event struct {
    Topic string
    Val   interface{}
}

type Observer interface {
    OnChange(ctx context.Context, e *Event) error
}

type EventBus interface {
    Subscribe(topic string, o Observer)
    UnSubscribe(topic string, o Observer)
    Publish(ctx context.Context, e *Event)
}
实现 Observer
type SimpleObserver struct {
    name string
}

func NewSimpleObserver() Observer {
    return &SimpleObserver{}
}

func (s *SimpleObserver) OnChange(ctx context.Context, e *Event) error {
    fmt.Printf("observer: %s, event key: %s, event val: %v", s.name, e.Topic, e.Val)
    return nil
}
实现 BaseEventBus
type BaseEventBus struct {
    mux       sync.RWMutex
    observers map[string]map[Observer]struct{}
}

func NewBaseEventBus() *BaseEventBus {
    return &BaseEventBus{
        observers: make(map[string]map[Observer]struct{}),
    }
}

func (b *BaseEventBus) Subscribe(topic string, o Observer) {
    b.mux.Lock()
    defer b.mux.Unlock()
    _, ok := b.observers[topic]
    if !ok {
        b.observers[topic] = make(map[Observer]struct{})
    }
    b.observers[topic][o] = struct{}{}
}

func (b *BaseEventBus) UnSubscribe(topic string, o Observer) {
    b.mux.Lock()
    defer b.mux.Unlock()
    delete(b.observers[topic], o)
}
实现 SyncEventBus
在同步模式下，采用串行遍历的方式对每个观察者进行通知，并对处理流程中遇到的错误进行聚合, 统一处理.
type SyncEventBus struct {
    *BaseEventBus
}

func NewSyncEventBus(base *BaseEventBus) EventBus {
    return &SyncEventBus{
        base,
    }
}

// 同步 event bus
func (s *SyncEventBus) Publish(ctx context.Context, e *Event) {
    s.mux.RLock()
    subscribers := s.observers[e.Topic]
    s.mux.RUnlock()

    errs := make(map[Observer]error)
    for subscriber := range subscribers {
        if err := subscriber.OnChange(ctx, e); err != nil {
            errs[subscriber] = err
        }
    }
    // 自定义错误处理
    // s.handleErr(ctx, errs)
}
实现 AsyncEventBus, 异步通知观察者，错误由后台的错误协程异步管理。
type AsyncEventBus struct {
    *BaseEventBus
    errC chan *ObserverWithErr
    ctx  context.Context
    stop context.CancelFunc
}

type ObserverWithErr struct {
    o   Observer
    err error
}

func NewAsyncEventBus(base *BaseEventBus) EventBus {
    asyncBus := &AsyncEventBus{
        BaseEventBus: base,
    }

    asyncBus.ctx, asyncBus.stop = context.WithCancel(context.Background())

    go asyncBus.handleErr()

    return asyncBus

}

func (s *AsyncEventBus) Publish(ctx context.Context, e *Event) {
    s.mux.RLock()
    subscribers := s.observers[e.Topic]
    s.mux.RUnlock()

    for subscriber := range subscribers {
        // shadow 避免并发问题
        subscriber := subscriber

        go func() {
            if err := subscriber.OnChange(s.ctx, e); err != nil {
                select {
                case <-s.ctx.Done():
                case s.errC <- &ObserverWithErr{
                    err: err,
                    o:   subscriber,
                }:
                }
            }
        }()
    }
}

func (s *AsyncEventBus) Stop() {
    s.stop()
}

func (s *AsyncEventBus) handleErr() {
    for {
        select {
        case <-s.ctx.Done():
            return
        case respErr := <-s.errC:
            // 处理 err
            fmt.Printf("observer: %v, err: %v", respErr.o, respErr.err)
        }
    }
}
构造者模式
含义： 类实例化的过程，初始化类属性。
场景： 很多第三方库当中，大家都见过这样的代码 NewRocketMQ(withHost('localhost')) 这就是构造者模式的思想。
实现：
package main

import "fmt"

type Options struct {
    host     string
    username string
    password string
}

type Option func(opts *Options)

func WithHost(host string) Option {
    return func(opts *Options) {
        opts.host = host
    }
}

func WithPassword(password string) Option {
    return func(opts *Options) {
        opts.password = password
    }
}

func WithUsername(username string) Option {
    return func(opts *Options) {
        opts.username = username
    }
}

// 兜底默认值
func repairOptions(opts *Options) {
    if opts.username == "" {
        opts.username = "root"
    }
}

func NewOptions(opts ...Option) *Options {
    optionsIns := &Options{}

    for _, opt := range opts {
        opt(optionsIns)
    }

    repairOptions(optionsIns)

    return optionsIns
}

// 应用 options 构造者模式
func main() {
    opt := NewOptions(WithHost("localhost"), WithPassword("654321"))
    fmt.Printf("options %+v", opt)
}
看完了？说点什么呢


小猫进化史
benjamin — Tue, 18 Feb 2025 05:21:50 GMT
该渲染由 Shiro API 生成，可能存在排版问题，最佳体验请前往：https://benlifec.com/notes/2
猫猫名字叫：长公主
刚带回来的时候，两个月



五个月

八个月
11个月
最近再做绝育，每天带着头套(戴 7 天，防止她舔舐伤口)
看完了？说点什么呢

Benjamin's website

一年程序员的认知成长：看问题的三个层次

一、三个层次：从表象到本质

1. 事件（浪花）：短促、孤立、容易被看到

2. 局势（潮汐）：关联、周期、可预测

3. 结构（气候/地理/生产关系）：稳定、底层、长期约束

二、事件，局势，结构的相互作用

三、如何训练“三层思维”

1. 观察：用提问清单强制分层

2. 学习：跨学科积累结构敏感度

3. 实践：用模拟推演验证

四、为什么程序员也该学“三层思维”

[JS] 我所理解的 JavaScript （下）

This

this 的四项绑定规则案例

this 绑定的优先级

new 绑定 > 显示绑定 > 隐式绑定 > 默认绑定。

特殊绑定

箭头函数当中的 this

this 面试题

异步

异步概述

异步解决方案

早期回调函数

Promise 处理异步回调

Promise 解决了什么样的问题

Promise 缺陷

async，await 处理异步回调

async 比 Promise的优势？

async 陷阱

async 继发和并发

async 错误捕获

async 的一些讨论

co 模块自动执行器

协程概念

生成器

生成器

生成器函数

生成器提前结束 - return 函数

生成器抛出异常 - throw 函数

抛出异常后我们可以在生成器函数中捕获异常

生成器代替迭代器

生成器原理

let | const | var

Set WeakSet | Map Weakmap

Dom | Bom

Bom

window

window 作为全局对象

window 常见的属性，方法和事件

window 继承自 EventTarget

location

location 方法

location 属性

history

history 属性

history 方法

Dom

继承 自 EventTarget

继承 Node

Document

Element

事件监听（事件流）

事件冒泡

事件捕获

事件代理

事件对象的属性和方法

[JS] 我所理解的 JavaScript （上）

闭包

为什么会产生闭包？

闭包有什么意义？

闭包的负面价值：内存泄露

原型

原型链本质和设计

作用域

作用域链

执行上下文

垃圾回收

引用计数算法

缺点

`async` 比 `Promise`的优势？

继承自 EventTarget

对于`<`和`>`比较符

|| 和 && 和？？操作符的返回值？

= 和与 Object.is()的区别

`RWMutex`

`RLock`

`RUnlock`

`Lock`

`UnLock`