1. charles 抓包

常见的抓包工具有Fiddler，charles，这里用的charles，先去官网 下载软件,然后打开微信客户端找到公众号，进入文章列表可以看到发过的文章。

不过charles没安装证书前获取不到https接口数据，显示unknown。

安装证书后在 proxy->ssl proxying settings 添加域名和host 。

再次抓取可以看到公众号文章接口数据了。

公众号文章的接口地址 https://mp.weixin.qq.com/mp/profile_ext?action=getmsg&__biz=MjM5ODIzNDEx&f=json&offset=25&count=10&is_ok=1&scene=124&uin=MTU0MTQzNj&key=f57423，参数比较多，其中有用的参数 __biz 是用户和公众号之间的唯一id，uin是用户的id，这个是不变的，key 是请求的秘钥，一段时间就会失效，offset 是偏移量，count 是每次请求的条数，返回值结构如下：

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

{
"ret": 0,
"errmsg": "ok",
"msg_count": 10,信息条数
"can_msg_continue": 1,是否还可以继续获取，1代表可以。0代表不可以，也就是最后一页
"general_msg_list": "{\"list\":[{\"comm_msg_info\":{\"id\":1000000182,\"type\":49,\"datetime\":1585702800,\"fakeid\":\"2398234112\",\"status\":2,\"content\":\"\"},\"app_msg_ext_info\":{\"title\":\"张国荣音乐\/演唱会\/电影全集网盘分享\",\"digest\":\"#17宠爱张国荣#\",\"content\":\"\",\"fileid\":0,\"content_url\":\"http:\/\/mp.weixin.qq.com\/s?__biz=MjM5ODIzNDExMg==&mid=2257484715&idx=1&sn=2fab0a11d62090d5e30e03e334bce636&chksm=a5b70ac492c083d275b6e15f0de85b8baf488ebb76e5429b08f40cdc53ab6e27b0ce5474fb30&scene=27#wechat_redirect\",\"source_url\":\"\",\"cover\":\"http:\/\/mmbiz.qpic.cn\/mmbiz_jpg\/pchiblEh3tErdgYu06FFVuvnKr9aAkddJLB7pgNhaiav0aYGQKJI0Dwn0kpT4wnmQkIglGH1Nciam5IThX19ibyEag\/0?wx_fmt=jpeg\",\"subtype\":9,\"is_multi\":0,\"multi_app_msg_item_list\":[],\"author\":\"苏生\",\"copyright_stat\":100,\"duration\":0,\"del_flag\":1,\"item_show_type\":0,\"audio_fileid\":0,\"play_url\":\"\",\"malicious_title_reason_id\":0,\"malicious_content_type\":0}}]}", 
"next_offset": 37,
"video_count": 1,
"use_video_tab": 1,
"real_type": 0,
"home_page_list": []
}

可以看到返回数据包括文章标题titile、摘要digest、文章地址content_url、阅读原文地址source_url、封面图cover、作者author ，只要抓取这些有用的数据就行了。

2. python 抓取公众号文章

上面分析了接口参数和返回数据，开始用Python请求微信接口就是了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94

import requests,json,time
biz = 'MzA5NjYxNDQwNA=='#随公众号改变（用户和公众号之间的唯一id）
uin = 'MTE3MDQ4MjQ0MQ%3D%3D'#不变（用户ID）
key = 'b7867b6712aa36fe784e610f7c7fc3a104955a476fa6bf7224e7f96ea3fc7bef0184aef8bd6832abbf4e9f3dfb09b23ead475e5c8aa84d1920618b8faf98820150bd2a001996d55bfc1421bcd2aa12094db071a65ede4c20f97af661292f93800cfa9d7c0e81d908dcebee5afa6a7baa4eb726a85321caaaa1ab3708118dbea4'
def parse(offset, biz, uin, key):
    # url前缀
    url = "https://mp.weixin.qq.com/mp/profile_ext"
    # 请求头
    headers = {
        "User-Agent": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 QBCore/4.0.1301.400 QQBrowser/9.0.2524.400 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2875.116 Safari/537.36 NetType/WIFI MicroMessenger/7.0.5 WindowsWechat"
    }
    proxies = {
        'https': None,
        'http': None,
    }
    # 重要参数https://mp.weixin.qq.com/mp/profile_ext?action=getmsg&__biz=MjM5ODIzNDExMg==&f=json&offset=48&count=10&is_ok=1&scene=124&uin=MTU0MTQzNjQwMw%3D%3D&key=a42654d5f06828b5d9e40deca0ea5f73004fecbf9ae4cfe0d37653465b623e26d82d0948a73d3cdf4fffd5df19bebafed06815f22f05bac0e5679625c86bb429885529cea1973bfb4d9f18481e624a0cea7cd12932fb55e7ed892ccd6dcda141737cf5ed9811d477cd90cdf4d8371a8b1bdd63de15e193787fc75f186cdf41b5&pass_ticket=FjDlSKDCqgdl0E5WNMPJLuBO3eeqP%2FdrlM1Q8%2FzEHxisVbm7ZVemLp6VeXsrLd0i&wxtoken=&appmsg_token=1074_NFjOFA%252FiWPMoGcRLiG7SzMUc-NoJp7QhKSYmYw~~&x5=0&f=json
    param = {
        'action': 'getmsg',
        '__biz': biz,
        'f': 'json',
        'offset': offset, #偏移量
        'count': '10', #每次请求的条数
        'is_ok': '1',
        'scene': '124',
        'uin': uin,
        'key': key, #请求的秘钥，一段时间就会失效
        'wxtoken': '',
        'x5': '0',
    }
    # 发送请求，获取响应
    response = requests.get(url, headers=headers, params=param, proxies=proxies)
    response_dict = response.json()
    print(response_dict)
    next_offset = response_dict['next_offset']
    can_msg_continue = response_dict['can_msg_continue']
    general_msg_list = response_dict['general_msg_list']
    data_list = json.loads(general_msg_list)['list']
    htmls = []
    # print(data_list)
    for data in data_list:
        try:
            # 文章发布时间
            date = time.strftime('%Y-%m-%d', time.localtime(data['comm_msg_info']['datetime']))
            msg_info = data['app_msg_ext_info']
            #原创
            if msg_info['copyright_stat'] == 11:
              # 文章标题
              title = msg_info['title']
              # 文章链接
              url = msg_info['content_url']
              #文章摘要digest
              #文章封面cover

              res = requests.get(url,proxies={'http': None,'https': None},verify=False, headers=headers)
              content = res.text.replace('data-src', 'src')
              #filename=str(int(time.time()))+'.html'
              #生成HTML文件
              #htmls.append(filename)
              with open(date+'_'+title+'.html', 'w', encoding='utf-8') as f:
                  f.write(content)
              #生成Excel
              #with open('wechat2.csv', 'a+', encoding='gbk') as f:
              #    f.write(title.replace(',', '，')+','+msg_info['digest'].replace(',', '，')+',' + msg_info['cover'].replace(',', '，') + ',' +url.replace(',', '，')+','+str(date)+ '\n')
              #生成markdown
            #   with open('wechat.md', 'a+', encoding='utf-8') as f:
            #      f.write('[{}]'.format(title) + '({})'.format(url)+ '\n')
              #生成PDF
              #try:
              #    pdfkit.from_string(content,'./' + date + '_' + title.replace(' ', '')+'.pdf')
              #except Exception as err:
              #    print(err)
              # 部分文章标题含特殊字符，不能作为文件名
                  #f = datetime.datetime.now().strftime('%Y%m%d%H%M%S') + '.pdf'
                  #pdfkit.from_string(content,f)
                  # 自己定义存储路径（绝对路径）
              #finally:
              #    os.remove(filename)
              #pdfkit.from_url(url, './' + date + title + '.pdf') #图片获取不到
              print(url + title + date + '成功')
        except Exception as err:
            print(err)
    #try:
        #pdfkit.from_file(htmls,'公众号文章备份.pdf')
    #except:
    #    pass
    if can_msg_continue == 1:
        time.sleep(1)
        parse(next_offset,biz,uin,key)
        return True
    else:
        print('爬取完毕')
        return False

parse(0,biz,uin,key)

在剪辑视频过程中，遇到一个长达18小时，大小8G的视频。而无论是发布平台还是各类剪辑工具都对视频的长度进行了限制，因此想到了通过FFmpeg的方式进行剪辑。目的便是将这个长达18小时的视频，通过FFmpeg将其裁剪为9个子视频，每个子视频长2小时。（以下为windows教程）

安装FFmpeg

1. 下载FFmpeg

1. 访问 FFmpeg 官方网站下载FFmpeg
2. 将下载的安装包解压到任意目录，例如 D:\ffmpeg（注意：解压目录不能含有中文）

2. 配置环境变量

1. 右键点击“我的电脑”，选择“属性”。
2. 点击“高级系统设置”。
3. 点击“环境变量”按钮。
4. 在“系统变量”区域找到名为“Path”的变量，并点击“编辑”。
5. 点击“新建”并输入 FFmpeg 的 bin 目录路径（例如：D:\ffmpeg\bin）。
6. 点击“确定”保存设置。

3. 验证安装

1. 打开命令提示符（cmd）或 PowerShell。
2. 输入 ffmpeg -version 命令，查看是否能正确显示 FFmpeg 版本信息。

编写并使用脚本

1. 编写脚本

打开你的文本编辑器，创建一个新的脚本文件，比如叫做split_video.sh，然后输入以下内容：

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

#!/bin/bash  
  
# 原始视频文件  
INPUT="original_video.mp4"  
  
# 开始时间偏移量，初始为0  
START=0  
# 每个视频的长度（秒），2小时 = 2 * 60 * 60秒  
DURATION=7200  
# 输出文件的前缀  
OUTPUT_PREFIX="part"  
  
# 循环裁剪视频  
for (( i=1; i<=9; i++ ))  
do  
    # 计算当前视频片段的结束时间  
    END=$((START + DURATION - 1))  
    # 构造输出文件名  
    OUTPUT="${OUTPUT_PREFIX}${i}.mp4"  
    # 使用ffmpeg裁剪视频  
    ffmpeg -ss $START -to $END -i "$INPUT" -c copy "$OUTPUT"  
    # 更新下一个视频片段的起始时间  
    START=$((START + DURATION))  
done  
  
echo "视频裁剪完成！"

注意：-ss 参数在 -i 前面（如脚本所示）时，ffmpeg会更快地定位到起始位置，因为它不会解码直到达到-ss指定的时间点。然而，这可能导致定位不太精确（尤其是当使用基于关键帧的编解码器时）。如果精确度非常重要，你可能需要将 -ss 移到 -i 参数之后，但这会增加处理时间，因为ffmpeg会先解码整个视频直到达到 -ss 指定的时间点。

2. 编译脚本

导航到脚本所在的目录，并运行以下命令：split_video.sh

1. 人工智能情绪和表情识别。可以识别我们的情绪，它可以在护理和陪伴等方面改善我们的日常生活。

2. 通用人工智能。使机器能够像人类一样行为、学习、创造和执行。AGI提出了耐人寻味的问题。我们是否总能分辨出与我们互动的对象是机器还是人类？这对我们来说重要吗？答案将以我们意想不到和无法预测的方式改变我们的生活。

3. 受生物启发的人工智能。包括进化计算和电子学、人工神经网络、免疫系统、生物机器人和蜂群智能，它从生物结构中汲取灵感，使计算能够模仿人类的大脑过程，可以为规划、记忆和视觉刺激提供新的算法。

4. 脑机接口技术。能将我们的思想转化为指令，从而控制外部软件或硬件，如：计算机或机械臂。它让我们更接近机器与人脑的完全对接。脑机接口技术可以用于医疗、老龄化社会、体育、军事、制造业、服务业等。

   
   国内研究团队利用脑机接口技术帮助中风患者康复（网络配图）

5. 量子算法。可应用于密码学、搜索优化和量子系统模拟等领域。从量子计算中获取价值的关键，在于找到量子计算机比经典计算机更擅长的特定算法集。

6. 脱氧核糖核酸（DNA）数据存储。对合成的脱氧核糖核酸或核糖核酸（RNA）链上的数据进行编码和解码。利用生物技术的力量可以满足我们不断升级的数据存储需求，这在我们希望获得复杂的人工智能技术时尤为重要。目前，我们的计算硬件设计已经达到物理极限，脱氧核糖核酸数据存储技术可以消除这一限制，开辟新的计算应用。

   
   国内研究团队研发的脱氧核糖核酸存储电极（网络配图）

7. 新计算模式。能提供传统计算机无法达到的数量级性能改进，包括：生物计算、光子计算和神经形态计算。新计算模式将使科学家们回答包括人脑建模、完整的气候模拟以及理解太空探索等问题。

8. 新颖的沉浸式界面。将模糊离线世界和在线世界。这一技术将改变我们观察世界和访问媒体的方式，让我们可以通过感官进行旅行。

9. 4D打印。具有“自我修复”的潜力，为太空制造、更好的软机器人技术和新的医疗解决方案提供了可能性。

4D打印抓手在最佳温度时抓取物体（网络配图）

10. 仿生材料。与同类材料相比，它们更容易重复使用和回收。它可以帮助人类创造出受自然启发、制造成本低、对地球危害小的材料。

11. 纳米粒子制造。就是制造纳米粒子。纳米技术已成为许多行业的基本技术，找到更有效、更高效和更低成本的纳米粒子制造方法，将有助于我们扩大纳米技术的用途和优势。

12. 超材料。在亚波长级别工作，扩展了光与物质的相互作用方式，可用于交通、医疗、科研、电信、能源、创意等领域。超材料是科幻小说与现实的结合，可以使与之相互作用的物质隐形，利用隐形技术可以消除汽车盲点，制造更精确的医疗成像、通讯天线，并显著提高太阳能发电机的效率。

13. 新型半导体替代系统。在越来越多的应用中，当前的半导体已经达到其性能极限。宽带隙（WBG）化合物半导体可以在更高的电压、温度和频率下工作，与目前的半导体相比，性能将大大提高。几乎所有行业都会受到这项技术的影响，主要用于6G、光子学和电力电子。

14. 新兴显微技术。能够在空间和时间上观察生物学的工作，从单个分子到整个生物体。这项技术能使科学家更准确地探索各种材料的结构与特性之间的关系，从而更好地了解它们的行为。这有助于我们开发新材料，更好地了解材料和生物体，以及更好地诊断疾病。

15. 高光谱成像。是将光谱学与多种频率的可见光波长以外的成像技术相结合，从而对物体的构成进行“指纹识别”（fingerprinting）。这项技术可以用于精准农业，使作物产量更高、更可靠；还能用于监测极端气候事件和更好地了解气候系统；以及通过更好的伤口分类和更清晰的微生物成像，为医疗保健带来潜在益处。

16. 毫米波和太赫兹技术。在无创传感和成像（包括医疗诊断）方面具有巨大潜力。毫米波或太赫兹波的传输距离比无线电波短，但可以传输更多数据。在成像应用中，它们能提供更高的空间分辨率，从而获得高清晰度图像；太赫兹波还可能会在蛋白质分析和药物发现中发挥作用；也能用于检测有毒气体和检查混凝土结构。

太赫兹人参皂苷检测仪（网络配图）

17. 光子发生器。是以单个粒子或光子形式发射光的光源。量子光是开发安全通信和由量子驱动的更强大计算的核心。

18. 等离子体学。涉及利用光照射到金属表面时引发的电子波，可应用于成像、纳米粒子，是其他新兴技术的重要推动力。等离子体学将主要影响科学、工程和医学界，此外还将对其他各行各业产生许多微小的影响。

19. 后量子密码学。侧重于开发既能确保量子计算机和经典计算机安全，又能在现有通信网络中运行的加密系统。量子计算将使目前使用的大多数加密解决方案变得不安全，因此我们需要使用后量子加密技术来应对未来的威胁。

20. 室温超导体。可以在不浪费能源的情况下进行导电，将使持续低电费成为可能，并从根本上改变能源生产和分配的经济性。

21. 交联聚合物回收。交联聚合物极难回收，不仅会增加垃圾填埋量，还会对环境造成危害。开发先进的回收方法可以减少塑料污染，并降低生产新聚合物对石油的需求。

22. 电网级无线能源传输和充电。在没有电缆的情况下安全地远距离传输电力，可能会改变我们使用电子设备的方式。实现不受天气影响的电力传输，让我们可以更轻松地将电力输送到需要的地方。

23. 高超音速。技术需要克服的关键挑战是，高超音速飞机周围的气流温度非常高，以至于化学键会发生振动并最终断裂。高超音速武器已经问世，高超音速运输将改变人员和货物的流动，如从伦敦到悉尼只需3小时。

高超音速技术已在军事领域获得运用（网络配图）

24. 新型推进或离子推进。通过给予电子能量使其脱离原子来产生推力。离子推力发动机只在太空中使用。与化学推进器相比，离子推进所需的推进剂要少得多，可帮助实现太空旅行，延长卫星寿命。在探索更深远的太空时，它可能成为推动我们前进的可靠技术。

25. 新型制氢和储氢技术。对于创造更廉价、更高效的制氢工艺至关重要。可以用于能源、原材料提取、运输、制造等。

26. 新型负排放技术。包括从环境中提取二氧化碳的所有新兴技术。通过清除地球大气中新的和现有的温室气体，可以帮助应对气候变化。

27. 核聚变。该技术仍然很难实现，但它或许能一举实现我们对清洁能源的追求。如果核聚变能够在地球上以工业规模复制，那么它几乎可以提供无限的清洁、安全、经济的能源。

28. 天基太阳能。可以全年全天候提供清洁能源，是去碳化进程中令人兴奋的一个组成部分。通过将太阳能电池阵列置于地球大气层之外来消除对天气的影响，意味着在地球上的任何地方都可以持续增加发电量。

29. 人造细胞和人造生命。已经用于治疗肾衰竭。随着发展，我们还能开发人造血细胞，减少献血需求，提高血液制品的安全性。人造细胞还可用于生物制造，生产长效、高产、高纯度的蛋白质和酶。

天然酿酒酵母与人造酿酒酵母对比（网络配图）

30. 细菌和微生物制造。细菌可用于制造药物（包括抗生素）、有用分子、生物混凝土和其他有趣的材料。细菌合成的物质可以创造出具有实用性的新材料。通过细菌制造产生的物质有望用于食品、个人护理、家用化学品、生物医学和纺织品等，几乎涵盖日常生活的方方面面。

31. 生物催化膜。具有一些有用的特性，如提高反应效率、改善污染物去除效果，以及在某些过程中能够重复使用酶。该技术目前已应用于制药和生物技术行业，可以促进更可持续、更高效、污染更少的制药生产方法。生物催化膜还可以生产出使营养成分在加热过程中不会流失的改良食品、新型药品，以及被用于废水处理。

32. 生物电子学和电子医药学。拓宽了无需药物或手术的治疗范围，并将推动无线供电等技术的发展。二者具有巨大的医疗保健效益，应用范围从心脏起搏器到治疗帕金森病的脑深部刺激。这些设备将使我们能够实时监测和治疗疾病。

33. 微生物遗传育种技术。为改善食品健康并提高生产效率提供了可能。该技术还可以通过单一技术减少污染并生产清洁能源。

34. 可编程细胞。将开辟治疗和预防疾病的新方法。对细胞行为进行编程拓展了生物计算的可能性。医药、能源、军事和农业都将从中受益。

35. 组织工程中的生物制造。可以灵活制造出满足人类和动物患者个性化需求的组织，甚至器官。这不仅有助于手术治疗，还能提高实验室研究的准确性，例如，确定有效的新药物。

36. 成人干细胞生成。是干细胞医学和再生疗法新领域的开端。可以帮助制造细胞，修复受伤的组织，如皮肤或大脑。此外成人可以同意使用自己的干细胞，因此与使用胚胎干细胞进行研究、治疗相比，争议要小得多。

37. 代谢流组。意义在于它收集了来自多个不同组学领域的数据，描绘了分子相互作用的全貌，将基因组学、转录组学、蛋白质组学和代谢组学等领域联系在一起。它可以帮助寻找和开发新的药物治疗方法或新的筛选技术，也是个性化医疗的关键推动因素。

38. 抗衰老药物。旨在影响老化和老年相关疾病的根源，延长动物的寿命。这些技术和相关治疗方法可以让我们健康地生活更长时间，减轻老年相关疾病给社会带来的负担，并有可能延长预期寿命。

39. 感知检测植入物。可以让装有假肢的人通过这些设备“感觉”自己，恢复或增强听觉或嗅觉。它还能为我们提供与机器互动的新方法。

    
    测试中的仿生眼（网络配图）

40. 抗生素替代品。抗生素用于预防和治疗细菌感染，但常见疾病的细菌正逐渐对抗生素产生耐药性。抗生素耐药性会导致医疗费用增加、住院时间延长和死亡率上升。因此开发替代品是全球健康的当务之急。抗生素替代品可应用于卫生、农业、动物保健行业。

41. 微生物组疗法。在降低许多人类疾病的发病率和严重程度方面具有巨大潜力，甚至将开创医学治疗的新领域。微生物组可以生产出本质上更适合人类使用的治疗方法和干预措施，因此可能比一般的临床方案更安全、更成功。

42. 个性化核糖核酸疗法。被开发用于癌症靶向治疗，未来将利用核糖核酸为患者提供个性化疗法。核糖核酸技术可将大量蛋白质、转录本和基因作为新的治疗靶点。

43. 分阶段基因组组装工具。可以采用新的基因组测序方法，加快生物信息学方面的工作，同时降低错误率。下一代测序可以进行全基因组分期，为复杂性状研究，以及遗传疾病的研究提供信息。

44. 全身芯片设备。可以确定药物在其他器官中的疗效和毒性，为临床试验前的治疗测试提供更准确、更具成本效益的方法。

45. 完全自主车辆。将做到人类驾驶员能做的任何事情。自动驾驶汽车的开发已经取得了进展，但完全自主车辆才是最终目标。这项技术引发了关于伦理、法律和保险的相关讨论。它可以从根本上改变个人交通方式，并大大增加无法开车之人的出行机会。

46. 纳米级机器人技术。能制造出极小的机器或机器人。微型机器人和纳米机器人正应用于生物医学等多个领域，比如“修复”遗传密码缺陷或高度靶向性的药物输送。它们也是连接人体与数字世界的另一种方式。

47. 机器人异地制造。对于人类在我们目前的星球之外生活是必不可少的。在太空制造，受益于微重力和真空等效应，将意味着我们可以开发出在地球上无法实现的产品。此外，在地球之外制造产品所需的技术，也是在月球或火星建立任何定居点的重要一步。

48. 软体机器人。具有与活体组织相似的机械特性，其灵感通常来自乌贼或蠕虫等无脊椎动物。它可以拓宽机器人技术在社会和工业中的应用范围。软体机器人让我们能够开发与生物系统更加相似的人造肌肉和人造器官。

    
    斯坦福大学制造的可任意变形和自由漫步的软体机器人（网络配图）

49. 空间核动力和新型空间推进系统。用于航天器的新型非燃烧推进。目前的推进方法需要笨重的燃料。这些技术的开发对于未来的载人太空探索至关重要。

50. 极近地轨道卫星。有两大好处：卫星图像的分辨率大幅提高；由于空间碎片不会在这一高度堆积，因此损坏的几率较小。电信、农业、环境监测、海洋监测等行业均可以应用这一技术。

书写模式是为了支持不同语言的书写习惯而生的，比如：中文、英文、法语等都是从左到右书写的，而文言文是从上到下书写的，但是阿拉伯语则是从右往左书写的。

下面是一个例子：

1
2
3
4
5
6
7
8
9

<body>
  <div style="width: 100px;">Hello World 1234我就是一段普普通通的文字，默认效果</div>
  <br />
  <div style="width: 100px; writing-mode: horizontal-tb;">Hello World 1234我就是一段普普通通的文字，从左往右从上到下水平书写的</div>
  <br />
  <div style="height: 100px; writing-mode: vertical-lr;">Hello World 1234我就是一段普普通通的文字，从上到下从左到右垂直书写的</div>
  <br />
  <div style="height: 100px; writing-mode: vertical-rl;">Hello World 1234我就是一段普普通通的文字，从上到下从右到左垂直书写的</div>
</body>

效果图如下：

配合 HTML 的 dir 属性和 CSS 的 direction 属性还可以改变元素从左到右排还是从右到左排，他们在配合 writing-mode 使用之后会有不同的效果。

1
2
3
4
5

<body dir="rtl">
  <div>Hello World 1234我就是一段普普通通的文字</div>
  <br />
  <div style="direction: ltr;">Hello World 1234我就是一段普普通通的文字</div>
</body>

效果：

物理属性

物理属性即含有 left、right、top 和 bottom 物理位置关键字的属性，它们与你看到的屏幕紧密相关，左永远是左，不管文本流动的方向如何。

物理属性在我们修改书写模式之后可能会存在一些问题，请看下面这个例子：

首先是中文：

1
2
3
4
5

<body>
   <div style="direction: ltr;">
     <div style="margin-left: 20px; margin-top: 10px;">中文TITLE</div>
   </div>
 </body>

然后是阿拉伯语：

1
2
3
4
5

<body>
  <div style="direction: rtl;">
    <div style="margin-left: 20px; margin-top: 10px;">              </div>
  </div>
</body>

看出问题了吗？如果我们是一个国际化的项目，当我们切换成阿拉伯语之后，按照阿拉伯语的书写习惯，margin 应该在右侧才对，那么只是单纯的切换 direction 还不行，还得改 CSS 代码。不过使用逻辑属性编写就不需要修改 CSS 代码了。

逻辑属性

逻辑属性定义了在相对方向下与对应的实体属性相等价的属性。

现在我们就可以利用逻辑属性来解决上面的问题了：

1
2
3
4
5

<body>
  <div style="direction: rtl;">
    <div style="margin-inline-start: 20px; margin-block-start: 10px;">              </div>
  </div>
</body>

font-family 其实不能简单理解为字体，它实际上是一个优先级从高到低的一个字体列表或者字体族名列表，前面的字体（或族名）如果系统没有就继续找后面的字体（或族名），直到找到为止。

另外，我们通常写的 serif、monospace、monospace、Helvetica 等也不是字体，而是字体族名，是用来描述一组相似设计风格的字体的名称，它们通常由一个主要的字体家族名称和一些特定字体样式组成。

例如，Helvetica 是一个常见的字体族名，其中包含了 Helvetica Regular、Helvetica Bold、Helvetica Italic 等字体样式。

常见字体族名：

• serif：带衬线字体，笔画结尾有特殊的装饰线或衬线。
• sans-serif：无衬线字体，即笔画结尾是平滑的字体。
• monospace：等宽字体，即字体中每个字宽度相同。
• cursive：草书字体。这种字体有的有连笔，有的还有特殊的斜体效果。因为一般这种字体都有一点连笔效果，所以会给人一种手写的感觉。
• system-ui：从浏览器所处平台处获取的默认用户界面字体。由于世界各地的排版习惯之间有很大的差异，因此为那些不适合其他通用字体的字体提供了这个通用字体。

1
2
3
4
5
6
7
8

<div>Hello World! 你好世界！</div>
<div style="font-family: serif;">serif Hello World! 你好世界！</div>
<div style="font-family: sans-serif;">sans-serif Hello World! 你好世界！</div>
<div style="font-family: monospace;">monospace Hello World! 你好世界！</div>
<div style="font-family: cursive;">cursive Hello World! 你好世界！</div>
<div style="font-family: system-ui;">system-ui Hello World! 你好世界！</div>
<div style="font-family: Arial, Helvetica, sans-serif;">Arial, Helvetica, sans-serif Hello World! 你好世界！</div>
<div style="font-family: 'Courier New', Courier, monospace">'Courier New', Courier, monospace Hello World! 你好世界！</div>

效果如下图所示：

2. 外部字体引入

外部字体引入的第一步是定义字体，使用 @font-face 关键字定义字体，然后再用 font-famliy 使用即可。

比如，我这里在网上下了一个字体叫”美神勇兔生肖“。

1
2
3
4
5
6

@font-face {
   font-family: MeiShenYongTuShengXiao;
   src: url('./MeiShenYongTuShengXiao.ttf');
 }
 
<h1 style="font-family: MeiShenYongTuShengXiao;">Hello World! 你好世界！</h1>

效果如下图所示：

导读：

德国当代知名哲学家、社会学家哈贝马斯近日在《南德意志报》发表文章谈论他对乌克兰战争的看法。在文章中，哈贝马斯指出，乌克兰正在就德国前几任总理的对俄战略“误判”对德国进行道德勒索，而西方在决定不参战的时候，就已经注定陷入两难：西方不可能无限制地投入对乌克兰的武装援助。哈贝马斯赞成德国总理朔尔茨坚持“负责任的权衡”，认为德国外长贝尔伯克对乌克兰的“仓促认同”实际上代表着德国和平主义者正在发生深刻转折，这一转折有可能预示着以对话和维护和平为主旨的德国政治模式的终结。哈贝马斯谨慎表达了对这些“前和平主义者”草率的情感认同的忧虑，对于哈贝马斯来说，如今不能再以传统意义上“失败”或者“胜利”来设想战争结局，不能指望任何一方落败。正因如此，他支持向谈判开放，并提出了欧盟自主的紧迫命题。欧亚系统科学研究会特转发本文，供读者思考。文章由“新华二代在德国”翻译，仅代表作者本人观点。

▲ 尤尔根·哈贝马斯，德国当代最重要的哲学家、社会学家之一。图源：openkat.eu

在距上一场战争77年之后，在和平仅靠均等的威慑才得以维持且仍旧危机四伏的时代结束33年之后，战争的震撼图景又回来了——就在我们的家门口，俄罗斯专横地挑起了战端。为媒体所呈现的战事前所未有地占据了我们的日常生活。一位深谙图像力量的乌克兰总统带来了令人印象深刻的消息。残暴的破坏场景和触动人心的苦难画面日日更新，并在西方社交媒体中激起了不断自我放大的回响。比起习惯于媒体的年轻人来说，我们老一辈人或许对难以预期的战事的展现方式和经过精心计算的公众影响力的新颖之处更加印象深刻。

不过，尽管展示出来的图景都是精心编排的产物，但牵动着我们的神经的，令意识到战争近在咫尺的我们愈加受到震撼的，都是实实在在发生的事。因此对西方的观众来说，每一名死者都令他们更不安，每一位被害者都令他们更沮丧，每一个战争罪行都令他们更愤怒——随之增长的，还有以行动来反对它的愿望。

1 指责朔尔茨的人的自信和攻击性令人困惑

尽管持有相同的立场，但西方国家联盟的诸政府却开始采取各不相同的做法；德国爆发了一场出格的、由传媒界的声音煽动起来的观念斗争，主题是如何对被侵略的乌克兰进行军事援助，援助规模该有多大。无辜被侵略的乌克兰提出来的要求，将前几届德国联邦政府的政治误判和错误的路径选择迅速转化成了道德勒索，这些要求是如此地合情合理，正如它们在我们所有人心里激起的情绪、同情和援助意愿是如此地理所当然。

德国总理朔尔茨

在德国，在行动方面显得深思熟虑和谨慎保守的联邦政府遭到了激于义愤的指责，可这些责难者所显示出来的笃定的自信令我感到困惑。联邦总理在接受《明镜》采访时说的一句话提到了其政策的要点：“我们正在用一切手段对抗俄罗斯在乌克兰造成的损害，前提是这不会带来一场失控的事态升级，以至于给整个大陆、甚至是整个世界带来无可估量的损害。”**西方已然决定不以参战方的身份介入这场冲突，在此之后就存在一个风险界限，它排除了对武装乌克兰的无限制投入。**我国政府最近同盟友在拉姆施泰因达成的共同阵线（注：指4月26日在德国拉姆施泰因美军基地召开的针对乌克兰自卫问题的会议，美国邀请了来自 40个国家的国防部长和代表参加），以及拉夫罗夫重新做出的使用核武器的威胁，都再次将这一界限摆到了刺眼的光线之下。罔顾该界限，想要以进攻性的自信高调不断将联邦总理推向这一方向的人，忽视或误解了西方因为这场战争而陷入的两难；因为西方已经因不参战这一具有充分道德依据的决定而自缚双手。

2 联邦总理坚持做在政治上负责的权衡是正确的

当前的两难局面要求西方在两个极端之间进行充满风险的权衡——一端是乌克兰的败北，另一端是一场有限的冲突升级为第三次世界大战——这再明显不过了。一方面，我们已从冷战中得到了一条教训，即针对一个有核国家的战争已不再可能在任何理性的意义上“获胜”，至少不可能在一场热战的可以预期的时限之内通过军事手段实现。核武器的威胁潜力带来的后果是，受到威胁的一方，无论它自身是否拥有核武器，都无法用一场胜利来终结动用武力所造成的绝对无法承受的毁伤，最好的情况是用一种保全双方脸面的妥协来收场。**在此前提之下，不能指望任何一方落败，从而被迫以“失败者”的身份退场。**目前同战事并行开展的停火谈判就是这种观念的体现；双方都保留着将对方看作可能的谈判对象的目光。尽管俄罗斯的威胁潜力取决于西方相信普京会使用核生化武器。但事实上，过去数周里CIA已经警告说存在使用所谓“小型”核武器的现实危险（这类武器被研发出来的目的显然是令有核国家之间的战争再次成为可能）。这赋予了俄罗斯方面一种相对于北约的非对称优势，后者鉴于世界大战的毁灭性规模——多达四个有核国家会卷入其中——而不愿意成为参战方。

目前普京正在判断西方于何时越过国际法所定义的界限，之后他就可以将对乌克兰的军事援助视为西方名义上的参战。

鉴于必须无条件地避免世界毁灭的风险，这一判断的不确定性没有给冒险的下注行为留下任何操作空间。哪怕西方满不在乎地将使用“小型”核武器的“警告”作为一种风险纳入考量，即在最糟的情况下予以容忍，谁又能保证，到了这个地步还能制止事态升级？余留下的活动空间就是必须带着专业领域必不可少的知识和一切必要的、并不总是对公众开放的信息来小心地斟酌各种论据，以便做出有理有据的决断。西方从一开始就施加了严厉的制裁，他们事实上的参战早已不容怀疑，因此在军事援助方面每迈出新的一步都要小心斟酌，这样做是否会跨过那条因为取决于普京的定义权而并不确定的界线，从而成为名义上的参战国。

另一方面，由于这种不对称性，西方可以——正如俄方也知道的那样——不让自己被任意勒索。假使西方对乌克兰坐视不管，那么这不仅在政治道德的视角下是一桩丑闻，而且也不符合其自身的利益。因为在这种情况下西方就必然预料到，接下来将不得不在格鲁吉亚或摩尔多瓦再玩一遍和这回一样的俄罗斯轮盘赌——然后又会轮到谁？毫无疑问，只有在西方有充分的理由畏惧承担一场世界核大战的风险时，这种长远来看可能将西方逼至死胡同的不对称性才会持续存在。因此那种认为不能把普京逼至死角、否则他可能做出任何事的论据就遭到了驳斥，因为这种“畏惧的政策”会让对手放开手脚一步一步地推动冲突升级（Ralf Fücks发表于《南德意志报》的评论）。当然这种论据也只是确证了局势的难以预测。因为只要我们有充分的理由决定不作为新的参战方加入战争以守卫乌克兰，那么就必须从这一角度对军事援助的方式和规模加以评定。以理性可以接受的方式反对“畏惧的政策”的人，自身就已经在政治上负责且在事务上有着全面了解的权衡的论证空间里活动，而联邦总理奥拉夫·朔尔茨坚持这种权衡是正确的。

3 德国的主流媒体正在散布对普京的猜想

这里涉及到的是恪守对我们给自己划出的那条由法律所定义的界线的解读，在我们看来这种解读对普京来说也是值得认同的。那些激动地反对政府路线的人，当他们拒绝承认他们并不质疑的原则性决定的潜在后果时，就是前后矛盾的。不参战的决定并不意味着，西方只要还没有直接介入就不得不坐视乌克兰队独自对抗远胜于己的对手。乌克兰自己已决定不惜付出巨大牺牲也要继续抗争，而西方的武器供应显然能够对其进程产生积极影响。但在不亲手拿起武器的情况下寄希望于乌克兰打赢这场俄罗斯发起的残酷战争，这岂不是一厢情愿的自我欺骗？战争煽动者坐在观众席上大放厥词，他们的言论和其所处的位置是不匹配的。因为这种言论无法否定一个有可能孤注一掷的对手的不可预测性。西方的两难之处在于，西方只能通过自我限制的、始终不越过国际法所定义的参战行为红线的对乌军事援助来彰显其原则，即西方坚持欧洲各国边界的完整。

对进行着自我限制的军事援助加以冷静的斟酌本就不易，加上还要揣测是什么动机促使俄罗斯方面做出这一明显失算的决定，这事就变得愈加复杂。对普京个人的关注导致出现了五花八门的猜想，我们的主流媒体如今正在散布这些猜想，仿佛正处于臆想性的苏维埃学的全盛时期。现在占据主导的普京形象是一个坚定的修正主义者，这一观点至少需要我们理性地分析其利益诉求来加以平衡。即使普京认为苏联解体是个大错，把他看成一个异想天开的梦想家，认为他带着俄罗斯东正教的赐福并受到权威主义意识形态专家亚历山大·杜金的影响，把逐步重建大俄罗斯帝国当作自己毕生的政治使命，这种观点也很难反映其个性的全部真相。但基于这种心理投射又发展出了一个被广泛接受的设想，即普京的侵略意图已超出乌克兰而指向格鲁吉亚和摩尔多瓦，接着又延伸至已加入北约的波罗的海三国，并最终深入巴尔干半岛。

4 那能够在这场针对有核国家的战争中“获胜”吗？

普京是一位受妄想驱使着的历史怀旧者。但与这样的人物形象相悖的是：他有着社会地位不断跃升的履历，曾在克格勃受训、任职并发迹，是一个精于理性计算的权力强人。而乌克兰的西向以及白俄罗斯境内的政治反抗运动又增强了他对本国不断发展壮大的自由主义思想团体的政治抗议的顾虑。从这个角度来讲，一再上演的侵略行为或许更应看作是在沮丧地回应西方的拒绝态度——拒绝就普京的地缘政治议程展开磋商，特别是拒绝在国际上承认他违反国际法的占领区，以及拒绝也应包括乌克兰在内的“前沿地带”的中立化。此类以及类似的各种猜想只会加深这一两难困境的不确定性，而这一困境“要求最大程度的谨慎和克制”（ 这是Peter Graf Kielmansegg2022年4月19日发表于《法兰克福汇报》上的富有教益的分析文章的结语。）

但是，那如何解释在内政方面所掀起的关于由联邦总理朔尔茨不断强化的政策——这一政策试图在与欧盟伙伴和北约伙伴的协调一致中审慎地确保与乌克兰的团结——的激烈讨论呢？为了解开这些问题，我将撇开关于是否继续对已变得不可预测的普京采取缓和政策这一问题的争议，这一政策在苏联结束之前甚至之后都是成功的，而现在却被证明是一个重大错误；同样，我也将撇开德国政府所犯的、部分出于经济压力而使自己依赖进口自俄罗斯的廉价石油的错误。今天的这些争论所形成的短暂记忆，有一天将由历史学家的判断来决定。

但在“新的德国认同危机”这个意味深长的名称下所展开的争论则是另一番状况。这个争论现在就已经在探讨“时代转折”的影响，而这个时代转折最初仅涉及到德国的东方政策和国防预算。之所以说这个争论是不一般的，乃是因为它首先与那些倡导和平运动的人物的惊人转变有关，而且预告了德国人的那种不断受到右翼谴责、且实际上来之不易的战后心态的历史性转变，因此也预告了以对话和维护和平为主旨的德国政治模式的完全结束。

▲ 德国外长贝尔伯克

5 情绪激动的外交部长已经成了一个偶像

这种解读体现在那些被培养得对规范性问题尤为敏感的追随者的例子上，他们不掩饰自己的情绪，最大声地要求更强有力的参与。他们给人的印象是，全新的战争现实已经把他们从和平主义的幻想中惊醒。这也让人联想到已经成为偶像的外交部长，她在战争开始后就紧接着以令人信赖的肢体语言和忏悔式的言辞真实地表达了这种震惊。这并不是说，她以此并未代表在我国民众中普遍存在的同情心以及试图援助的冲动；但除此之外，她也让人信服地促成了对决心取胜的乌克兰领导层的急躁的道德说教的自发认同。这样，我们就触及到了两派人之间冲突的核心，一派人更为感同身受，但仓促地认同着一个国家为他们的自由、权利和生命而战的观点；另一派的人则从冷战的经历中吸取了不同的教训，并且——就像那些在我们的街头抗议的人那样——形成了不同的心态。一派人只能在胜利或失败的选项下来设想战争，而另一些人则知道，针对有核国家的战争已经无法在传统意义上“获胜”。

粗略来讲，民众偏民族性的心理和偏后民族性的心理构成了对战争的不同态度的背景。当我们把乌克兰人民令人钦佩的英勇抵抗和视死如归的牺牲精神与在类似情况下对“我们”——让我们宽泛地讲——西欧人民的期望相比，那这种差异就变得很明显。我们的钦佩中夹杂着某种惊讶，惊讶于士兵们以及为战斗而征召来的新兵们的必胜的信心和不屈不挠的勇气，他们冷峻地决心要保卫自己的祖国，对抗军事上远胜于他们的敌人。相比之下，我们西方国家则依靠职业军队，我们为之付费，以便在必要时，我们不必自己用手中的武器来保护自己，而可以由职业军人来保护。

6 另外, 仍然要与普京进行谈判

20世纪下半叶，在美国的核保护伞下，这种后英雄主义的心态在西欧——如果允许我这样泛化地来讲的话——得到了发展。鉴于核战争可能造成的大破坏，这样一种观点在政治精英和绝大多数民众中蔓延开来，即：国际冲突原则上只能通过外交和制裁来得到解决；在爆发军事冲突的情况下，战争必须尽快得到调停，因为鉴于难以估算的行将使用核生化武器的风险，战争基本上已经不能在传统意义上以胜利或失败而结束。**“人们从战争中唯独能学到的就是去创造和平”**，亚历山大·克鲁格（Alexander Kluge）这样说到。这种取向并不意味着全盘的和平主义，即不惜一切代价来保证和平。试图尽快结束毁灭性活动、结束人类的牺牲和反文明活动的这种倾向，并不等同于要求为了单纯保命而牺牲政治上的自由。看来，在面对专制窒息的生活所要求的代价时，对战争暴力手段的质疑就受到了限制——在那种生活中，甚至都还不会意识到强制的规范性与自我决定的生活之间的矛盾。

时代转折的右翼解释者们欢迎着我们以前的和平主义者的转变。这个转变，在我看来，乃是出于对那两种同时间互相冲突、但在历史上并不同时出现的心态的混淆。这个独特的群体与乌克兰人一样，对胜利充满着信心，并以极大的信心呼吁回到已受蹂躏的国际法。在布恰事件之后，“送普京去海牙！”的口号就飞快传开了。这在总体上表明了我们今天在国际关系方面所设的规范标准的自明性，亦即表明了民众的相应期望以及在人道主义方面的敏感度的实际变化程度。

在我这个年纪，我并不掩饰某种惊讶：甚至那保守的媒体都呼吁国际刑事法庭指派一名检察官，尽管该法庭既不被俄罗斯和中国也不被美国承认，可见我们的子孙今天生存于其上的、自然而然的文化土壤，已经被翻耕得多深了。可惜，在这样的现实状况中，对德国克制态度的日益尖锐的道德谴责所激起的广泛认同也仍旧暴露出空乏的基础。若要结束战争，或至少是停火，就仍需与普京进行谈判。我看不出有什么令人信服的理由来要求采取那种在事实上会使不参与这场战争的合理决定面临危险的政策，哪怕在极为痛苦地、愈加无法忍受地目睹每天的悲惨受害者的情景下。

7 前和平主义者的转变导致了错误和误解

从不同的历史发展时期中可以得到解释的那些政治心理差异，不应被联盟成员用于相互谴责；联盟成员们应将这些差异作为事实加以认识，并在合作中明智地将其考虑在内。但只要这些视角上的差异仍还处在背景中，那它们就只会造成情感上的混乱，即不成熟的赞同反应、对他人观点的单纯理解和被给予的自尊之间的杂混，就像是当乌克兰总统在联邦议院进行视频演讲并呼吁道德秩序的时候议员们做出反应时的状况那样。回顾历史，就可以解释人们在对战争的认识和解释上的差异。而忽视这些差异，则不仅会导致在相互交往中出现的重大错误，比如粗暴地拒绝德国联邦总统访问的情况。更糟的是，这将会导致彼此对对方实际想法和愿望的误解。

这种认识也使我们能够更清醒地理解前和平主义者的转变。因为构成他们草率要求之动机背景的是愤慨、惊恐和同情，而这些并不能从他们对所谓的现实主义者一向嘲讽的规范性取向的放弃当中得到解释,而恰是出自对这些原则的过于精简的解读。他们并未转变成现实主义者，而是一头栽进了现实主义：当然，没有道德感受，就没有道德判断；但普遍性的判断也反而纠正着在近处被激发起的感受的有限作用范围。

讨论“时代转折”的人是那些左派和自由主义者，这毕竟不是一个偶然。他们在一个急剧变化的大国局势面前，并且在跨大西洋关系的不确定性的阴影下，想要认真对待一个早该有的认识：欧盟，如果既不想让它的社会生活和政治生活方式从外部遭到破坏，也不想让它们在内部遭到侵蚀，那就**只有在军事上也能自立的情况下，才能具有政治上的行动力。**马克龙的连任标志着一种缓和。但首先我们必须从我们的困境中找到一个建设性的出口。这种希望反映在谨慎地提出乌克兰不能输掉这场战争的目标上。

项目中一直用的都是webpack，前一段需要开发几个类库供其他平台使用，本来打算继续用webpack的，但感觉webpack用来开发js库，不仅繁琐而且打包后的文件体积也比较大。正好之前看vue源码，知道vue也是通过rollup打包的。这次又是开发类库的，于是就快速上手了rollup。

本篇文章是我有了一定的项目实践后，回过来给大家分享一下如何从零快速上手rollup。

一、什么是rollup？

系统的了解rollup之前，我们先来简单了解下What is rollup？

关于rollup的介绍，官方文档已经写的很清楚了：

Rollup 是一个 JavaScript 模块打包器，可以将小块代码编译成大块复杂的代码，例如 library 或应用程序。

与Webpack偏向于应用打包的定位不同，rollup.js更专注于Javascript类库打包。

我们熟知的Vue、React等诸多知名框架或类库都是通过rollup.js进行打包的。

二、为什么是rollup？

webpack我相信做前端的同学大家都用过，那么为什么有些场景还要使用rollup呢？这里我简单对webpack和rollup做一个比较：

总体来说webpack和rollup在不同场景下，都能发挥自身优势作用。webpack对于代码分割和静态资源导入有着“先天优势”，并且支持热模块替换(HMR)，而rollup并不支持。

所以当开发应用时可以优先选择webpack，但是rollup对于代码的Tree-shaking和ES6模块有着算法优势上的支持，若你项目只需要打包出一个简单的bundle包，并是基于ES6模块开发的，可以考虑使用rollup。

其实webpack从2.0开始就已经支持Tree-shaking，并在使用babel-loader的情况下还可以支持es6 module的打包。实际上，rollup已经在渐渐地失去了当初的优势了。但是它并没有被抛弃，反而因其简单的API、使用方式被许多库开发者青睐，如React、Vue等，都是使用rollup作为构建工具的。

三、快速上手

我们先花大概十分钟左右的时间来了解下rollup的基本使用以及完成一个hello world。

1. 安装

首先全局安装rollup：

1

npm i rollup -g

2. 目录准备（hello world）

接着，我们初始化一个如下所示的项目目录

1
2
3
4
5
6

├── dist # 编译结果
├── example # HTML引用例子
│ └── index.html
├── package.json
└── src # 源码
└── index.js

首先我们在src/index.js中写入如下代码：

1

console.log("柯森");

然后在命令行执行以下命令：

1

rollup src/index.js -f umd -o dist/bundle.js

执行命令，我们即可在dist目录下生成bundle.js文件：

1
2
3
4
5
6
7
8

(function (factory) {
typeof define === 'function' && define.amd ? define(factory) :
factory();
}((function () { 'use strict';

console.log("柯森");

})));

这时，我们再在example/index.html中引入上面打包生成的bundle.js文件，打开浏览器：

如我们所预料的，控制台输出了柯森。

到这里，我们就用rollup打包了一个最最简单的demo。

可能很多同学看到这里对于上面命令行中的参数不是很明白，我依次说明下：

• -f。-f参数是–format的缩写，它表示生成代码的格式，amd表示采用AMD标准，cjs为CommonJS标准，esm（或 es）为ES模块标准。-f的值可以为amd、cjs、system、esm（’es’也可以）、iife或umd中的任何一个。
• -o。-o指定了输出的路径，这里我们将打包后的文件输出到dist目录下的bundle.js

其实除了这两个，还有很多其他常用的命令（这里我暂且列举剩下两个也比较常用的，完整的rollup 命令行参数）：

• -c。指定rollup的配置文件。
• -w。监听源文件是否有改动，如果有改动，重新打包。

3. 使用配置文件(rollup.config.js)

使用命令行的方式，如果选项少没什么问题，但是如果添加更多的选项，这种命令行的方式就显得麻烦了。

为此，我们可以创建配置文件来囊括所需的选项

在项目中创建一个名为rollup.config.js的文件，增加如下代码：

1
2
3
4
5
6
7
8

export default {
  input: ["./src/index.js"],
  output: {
    file: "./dist/bundle.js",
    format: "umd",
    name: "experience",
  },
};

然后命令行执行：

1

rollup -c

打开dist/bundle.js文件，我们会发现和上面采用命令行的方式打包出来的结果是一样的。

这里，我对配置文件的选项做下简单的说明：

• input表示入口文件的路径（老版本为 entry，已经废弃）

• output表示输出文件的内容，它允许传入一个对象或一个数组，当为数组时，依次输出多个文件，它包含以下内容：

• • output.file：输出文件的路径（老版本为 dest，已经废弃）
  • output.format：输出文件的格式
  • output.banner：文件头部添加的内容
  • output.footer：文件末尾添加的内容

到这里，相信你已经差不多上手rollup了。

四、进阶

但是，这对于真实的业务场景是远远不够的。

下面，我将介绍rollup中的几种常用的插件以及external属性、tree-shaking机制。

1. resolve插件

（1）为什么要使用resolve插件

在上面的入门案例中，我们打包的对象是本地的js代码和库，但实际开发中，不太可能所有的库都位于本地，我们大多会通过npm下载远程的库。

与webpack和browserify这样的其他捆绑包不同，rollup不知道如何打破常规去处理这些依赖。因此我们需要添加一些配置。

（2）resolve插件使用

首先在我们的项目中添加一个依赖the-answer，然后修改src/index.js文件:

1
2
3
4
5

import answer from "the-answer";

export default function () {
  console.log("the answer is " + answer);
}

执行npm run build。

这里为了方便，我将原本的rollup -c -w添加到了package.json的scripts中：”build”: “rollup -c -w”

会得到以下报错：

打包后的bundle.js仍然会在Node.js中工作，但是the-answer不包含在包中。为了解决这个问题，将我们编写的源码与依赖的第三方库进行合并，rollup.js为我们提供了resolve插件。

首先，安装resolve插件：

1

npm i -D @rollup/plugin-node-resolve

修改配置文件rollup.config.js：

1
2
3
4
5
6
7
8
9
10
11

import resolve from "@rollup/plugin-node-resolve";

export default {
  input: ["./src/index.js"],
  output: {
    file: "./dist/bundle.js",
    format: "umd",
    name: "experience",
  },
  plugins: [resolve()],
};

这时再次执行npm run build，可以发现报错已经没有了：

打开dist/bundle.js文件：

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

(function (global, factory) {
  typeof exports === "object" && typeof module !== "undefined"
    ? (module.exports = factory())
    : typeof define === "function" && define.amd
    ? define(factory)
    : ((global =
        typeof globalThis !== "undefined" ? globalThis : global || self),
      (global.experience = factory()));
})(this, function () {
  "use strict";

  var index = 42;

  function index$1() {
    console.log("the answer is " + index);
  }

  return index$1;
});

打包文件bundle.js中已经包含了引用的模块。

有些场景下，虽然我们使用了resolve插件，但可能我们仍然想要某些库保持外部引用状态，这时我们就需要使用external属性，来告诉rollup.js哪些是外部的类库。

2. external 属性

修改rollup.js的配置文件：

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

import resolve from "@rollup/plugin-node-resolve";

export default {
  input: ["./src/index.js"],
  output: {
    file: "./dist/bundle.js",
    format: "umd",
    name: "experience",
  },
  plugins: [resolve()],
  external: ["the-answer"],
};

重新打包，打开dist/bundle.js文件：

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

(function (global, factory) {
  typeof exports === "object" && typeof module !== "undefined"
    ? (module.exports = factory(require("the-answer")))
    : typeof define === "function" && define.amd
    ? define(["the-answer"], factory)
    : ((global =
        typeof globalThis !== "undefined" ? globalThis : global || self),
      (global.experience = factory(global.answer)));
})(this, function (answer) {
  "use strict";

  function _interopDefaultLegacy(e) {
    return e && typeof e === "object" && "default" in e ? e : { default: e };
  }

  var answer__default = /*#__PURE__*/ _interopDefaultLegacy(answer);

  function index() {
    console.log("the answer is " + answer__default["default"]);
  }

  return index;
});

这时我们看到the-answer已经是做为外部库被引入了。

3. commonjs插件

（1）为什么需要commonjs插件

rollup.js编译源码中的模块引用默认只支持 ES6+的模块方式import/export。然而大量的npm模块是基于CommonJS模块方式，这就导致了大量 npm模块不能直接编译使用。

因此使得rollup.js编译支持npm模块和CommonJS模块方式的插件就应运而生：@rollup/plugin-commonjs。

（2）commonjs插件使用

首先，安装该模块：

1

npm i -D @rollup/plugin-commonjs

然后修改rollup.config.js文件：

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

import resolve from "@rollup/plugin-node-resolve";
import commonjs from "@rollup/plugin-commonjs";
export default {
  input: ["./src/index.js"],
  output: {
    file: "./dist/bundle.js",
    format: "umd",
    name: "experience",
  },
  plugins: [resolve(), commonjs()],
  external: ["the-answer"],
};

4. babel插件

（1）为什么需要babel插件？

我们在src目录下添加es6.js文件(⚠️ 这里我们使用了 es6 中的箭头函数)：

1
2
3
4
5
6

const a = 1;
const b = 2;
console.log(a, b);
export default () => {
  return a + b;
};

然后修改rollup.config.js配置文件：

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

import resolve from "@rollup/plugin-node-resolve";
import commonjs from "@rollup/plugin-commonjs";
export default {
  input: ["./src/es6.js"],
  output: {
    file: "./dist/esBundle.js",
    format: "umd",
    name: "experience",
  },
  plugins: [resolve(), commonjs()],
  external: ["the-answer"],
};

执行打包，可以看到dist/esBundle.js文件内容如下：

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

(function (global, factory) {
  typeof exports === "object" && typeof module !== "undefined"
    ? (module.exports = factory())
    : typeof define === "function" && define.amd
    ? define(factory)
    : ((global =
        typeof globalThis !== "undefined" ? globalThis : global || self),
      (global.experience = factory()));
})(this, function () {
  "use strict";

  const a = 1;
  const b = 2;
  console.log(a, b);
  var es6 = () => {
    return a + b;
  };

  return es6;
});

可以看到箭头函数被保留下来，这样的代码在不支持ES6的环境下将无法运行。我们期望在rollup.js打包的过程中就能使用babel完成代码转换，因此我们需要babel插件。

（2）babel插件的使用

首先，安装：

1

npm i -D @rollup/plugin-babel

同样修改配置文件rollup.config.js：

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

import resolve from "@rollup/plugin-node-resolve";
import commonjs from "@rollup/plugin-commonjs";
import babel from "@rollup/plugin-babel";

export default {
  input: ["./src/es6.js"],
  output: {
    file: "./dist/esBundle.js",
    format: "umd",
    name: "experience",
  },
  plugins: [resolve(), commonjs(), babel()],
  external: ["the-answer"],
};

然后打包，发现会出现报错：

提示我们缺少@babel/core，因为@babel/core是babel的核心。我们来进行安装：

1

npm i @babel/core

再次执行打包，发现这次没有报错了，但是我们尝试打开dist/esBundle.js：

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

(function (global, factory) {
  typeof exports === "object" && typeof module !== "undefined"
    ? (module.exports = factory())
    : typeof define === "function" && define.amd
    ? define(factory)
    : ((global =
        typeof globalThis !== "undefined" ? globalThis : global || self),
      (global.experience = factory()));
})(this, function () {
  "use strict";

  const a = 1;
  const b = 2;
  console.log(a, b);
  var es6 = () => {
    return a + b;
  };

  return es6;
});

可以发现箭头函数仍然存在，显然这是不正确的，说明我们的babel插件没有起到作用。这是为什么呢？

原因是由于我们缺少.babelrc文件，添加该文件：

1
2
3
4
5
6
7
8
9
10
11

{
  "presets": [
    [
    "@babel/preset-env",
      {
        "modules": false,
        // "useBuiltIns": "usage"
      }
    ]
  ]
}

我们看.babelrc配置了preset env，所以先安装这个插件：

1

npm i @babel/preset-env

这次再次执行打包，我们打开dist/esBundle.js文件：

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

(function (global, factory) {
  typeof exports === "object" && typeof module !== "undefined"
    ? (module.exports = factory())
    : typeof define === "function" && define.amd
    ? define(factory)
    : ((global =
        typeof globalThis !== "undefined" ? globalThis : global || self),
      (global.experience = factory()));
})(this, function () {
  "use strict";

  var a = 1;
  var b = 2;
  console.log(a, b);
  var es6 = function () {
    return a + b;
  };

  return es6;
});

可以看到箭头函数被转换为了function，说明babel插件正常工作。

5. json插件

（1）为什么要使用json插件？

在src目录下创建json.js文件：

1
2

import json from "../package.json";
console.log(json.author);

内容很简单，就是引入package.json，然后去打印author字段。

修改rollup.config.js配置文件：

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

import resolve from "@rollup/plugin-node-resolve";
import commonjs from "@rollup/plugin-commonjs";
import babel from "@rollup/plugin-babel";

export default {
  input: ["./src/json.js"],
  output: {
    file: "./dist/jsonBundle.js",
    format: "umd",
    name: "experience",
  },
  plugins: [resolve(), commonjs(), babel()],
  external: ["the-answer"],
};

执行打包，发现会发生如下报错：

提示我们缺少@rollup/plugin-json插件来支持json文件。

（2）json插件的使用

来安装该插件：

1

npm i -D @rollup/plugin-json

同样修改下配置文件，将插件加入plugins数组即可。

然后再次打包，发现打包成功了，我们打开生成的dist/jsonBundle目录：

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

(function (factory) {
  typeof define === "function" && define.amd ? define(factory) : factory();
})(function () {
  "use strict";

  var name = "rollup-experience";
  var version = "1.0.0";
  var description = "";
  var main = "index.js";
  var directories = {
    example: "example",
  };
  var scripts = {
    build: "rollup -c -w",
    test: 'echo "Error: no test specified" && exit 1',
  };
  var author = "Cosen";
  var license = "ISC";
  var dependencies = {
    "@babel/core": "^7.11.6",
    "@babel/preset-env": "^7.11.5",
    "the-answer": "^1.0.0",
  };
  var devDependencies = {
    "@rollup/plugin-babel": "^5.2.0",
    "@rollup/plugin-commonjs": "^15.0.0",
    "@rollup/plugin-json": "^4.1.0",
    "@rollup/plugin-node-resolve": "^9.0.0",
  };
  var json = {
    name: name,
    version: version,
    description: description,
    main: main,
    directories: directories,
    scripts: scripts,
    author: author,
    license: license,
    dependencies: dependencies,
    devDependencies: devDependencies,
  };

  console.log(json.author);
});

完美！！

6. tree-shaking机制

这里我们以最开始的src/index.js为例进行说明：

1
2
3
4
5

import answer from "the-answer";

export default function () {
  console.log("the answer is " + answer);
}

修改上述文件：

1
2
3
4
5

const a = 1;
const b = 2;
export default function () {
  console.log(a + b);
}

执行打包。打开dist/bundle.js文件：

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

(function (global, factory) {
  typeof exports === "object" && typeof module !== "undefined"
    ? (module.exports = factory())
    : typeof define === "function" && define.amd
    ? define(factory)
    : ((global =
        typeof globalThis !== "undefined" ? globalThis : global || self),
      (global.experience = factory()));
})(this, function () {
  "use strict";

  var a = 1;
  var b = 2;
  function index() {
    console.log(a + b);
  }

  return index;
});

再次修改src/index.js文件：

1
2
3
4
5

const a = 1;
const b = 2;
export default function () {
  console.log(a);
}

再次执行打包，打开打包文件：

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

(function (global, factory) {
  typeof exports === "object" && typeof module !== "undefined"
    ? (module.exports = factory())
    : typeof define === "function" && define.amd
    ? define(factory)
    : ((global =
        typeof globalThis !== "undefined" ? globalThis : global || self),
      (global.experience = factory()));
})(this, function () {
  "use strict";

  var a = 1;
  function index() {
    console.log(a);
  }

  return index;
});

发现了什么？

我们发现关于变量b的定义没有了，因为源码中并没有用到这个变量。这就是ES模块著名的tree-shaking机制，它动态地清除没有被使用过的代码，使得代码更加精简，从而可以使得我们的类库获得更快的加载速度。

五、总结

本文大致向大家介绍了什么是rollup以及如何快速上手rollup。文中提到的这些其实只是冰山一角，rollup能玩的东西还有很多，关于更多可以去rollup 官网查询

1、workspace：pnpm中使用workspace协议的目的是将拒绝解析除本地 workspace 包含的 package 之外的任何内容。也就是说如果引入的项目需要强制使用本地包，则可以使用workspace:协议 。

2、微前端和Monorepo的关系：Monorepo是一种单仓库多应用的代码管理方式。微前端是一种实现了多个子项目间样式隔离、JS隔离、路由、子项目通信等功能的项目架构模式。微前端使用Monorepo进行代码管理可以实现共享工程配置，同时又快捷地共享模块代码的功能。

3、pnpm：在使用monorepo方式管理项目时，会产生诸多问题，如幽灵依赖、依赖安装耗时的问题，需要使用pnpm进行解决这类问题。

所以，当仅仅需要对多个子项目间共享工程配置和模块间代码共享时使用Monorepo进行代码管理即可。

而当需要继承多个不同栈的模块或服务、每个模块需要独立开发部署、需要支持独立的生命周期和版本控制等时使用微前端。

在开发项目的过程中，我们需要在一个仓库中管理多个项目，每个项目有独立的依赖、脚手架，这种形式的项目结构我们称之为Monorepo，pnpm workspace就是管理这类项目的方案之一。

一、pnpm

pnpm代表performance npm（高性能的npmn），同npm和yarn，都属于javascript包管理安装工具，它较npm和yarn在性能上得到很大提升，被称为 快速地，节省磁盘空间的包管理工具。

二、对比lerna+yarn

使用lerna+yarn组合，也可以实现Monorepo项目管理。但是相比来说，更推荐pnpm workspace来管理。

三、构建一个Monorepo

先上最终的项目结构：

1
2
3
4
5

Monorepo
- umi-antd
- web
-- common1
-- common2

如上图，我们最终要创建如上图的一个项目结构，其中umi-antd是主项目，web文件夹下的都是子项目，供umi-antd调用。

1、创建主项目

主项目这里是使用的umi项目，这里也可以构建基于其他打包工具的各类项目，只要是遵守package.json配置条例的项目，都是可以的。

构建umi项目

1

pnpm dlx create-umi@latest

这里选择创建Ant Design Pro项目。

1
2
3
4
5

$ npx create-umi@latest
? Pick Umi App Template › - Use arrow-keys. Return to submit.
Simple App
❯ Ant Design Pro
Vue Simple App

2、创建子项目common1

• 进入Monorepo>web目录，创建common1文件夹
• 然后进入common1目录，执行命令npm init对项目进行初始化，这时候会生产一个package.json文件

新建index.ts文件，代码如下：

1
2
3

export default function print(msg:string) {
    console.log(msg);
}

3、创建子项目common2

步骤和创建common1一致

4、主项目中引入子项目

安装common1和common2。

1
2

pnpm -F umi-antd add common1
pnpm -F umi-antd add common2

安装完成后，在umi-antd依赖中出现两个子项目的软链接（或者叫符号链接）。

在业务代码中调用子项目输出的方法：

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

//umi-antd\src\pages\Home\index.tsx

import Guide from '@/components/Guide';
import { trim } from '@/utils/format';
import { PageContainer } from '@ant-design/pro-components';
import { useModel } from '@umijs/max';
import styles from './index.less';
import print1 from 'common1';
import print2 from 'common2';

const HomePage: React.FC = () => {
  const { name } = useModel('global');
  print1("umi-antd中调用common1");
  print2("umi-antd中调用common2");
  return (
    <PageContainer ghost>
      <div className={styles.container}>
        <Guide name={trim(name)} />
      </div>
    </PageContainer>
  );
};

export default HomePage;

5、运行主项目

到这里基本搭建完毕，这时候的整体项目结构如图：

然后执行命令启动主项目：pnpm -F umi-antd start，我们可以看到，控制台打印出来子模块中的信息。

6、子模块调用子模块

子模块也是可以相互调用的，这里我们在common1中引入common2的方法。

• 执行命令pnpm -F common1 add common2

• 在common1中调用common2中方法，代码如下：

  1 2 3 4 5 6

  //web\common1\index.ts import print2 from 'common2'; export default function print(msg:string) { console.log(msg); print2("这里是common1中调用common2"); }

再次运行umi-antd项目时，我们可以看到，控制台已经打印了common2中方法。

四、workspace协议(workspace:)

1、协议概述

默认情况下，如果可用的 packages 与已声明的可用范围相匹配，pnpm 将从工作区链接这些 packages。 例如, 如果bar引用”foo”: “^1.0.0”并且foo@1.0.0存在工作区，那么pnpm会从工作区将foo@1.0.0链接到bar。 但是，如果 bar 的依赖项中有 “foo”: “2.0.0”，而 foo@2.0.0 在工作空间中并不存在，则将从 npm registry 安装 foo@2.0.0 。 这种行为带来了一些不确定性。

幸运的是，pnpm 支持 workspace 协议 workspace: 。 当使用此协议时，pnpm 将拒绝解析除本地 workspace 包含的 package 之外的任何内容。 因此，如果您设置为 “foo”: “workspace:2.0.0” 时，安装将会失败，因为 “foo@2.0.0“ 不存在于此 workspace 中。

当 link-workspace-packages 选项被设置为 false 时，这个协议将特别有用。 在这种情况下，仅当使用 workspace: 协议声明依赖，pnpm 才会从此 workspace 链接所需的包。

以上是官网的解释，实际在使用的时候，如果引入的项目需要强制使用本地包，则可以使用workspace:协议。改造下umi-antd的package.json文件如下：

1
2
3
4
5
6
7
8

"dependencies": {
    "@ant-design/icons": "^5.0.1",
    "@ant-design/pro-components": "^2.4.4",
    "@umijs/max": "^4.0.76",
    "antd": "^5.4.0",
    "common1": "workspace:^",
    "common2": "workspace:^"
  },

上面加上common1和common2的依赖声明后，会强制到本地寻找，找不到也不会到npm registry对应的私仓去下载。

2、版本符号

workspace协议，区分*、~、^、版本号，表示的意义各部相同，具体如下：

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

{
    "dependencies": {
        "foo": "workspace:*",
        "bar": "workspace:~",
        "qar": "workspace:^",
        "zoo": "workspace:^1.5.0"
    }
}
// 将会被转化为：
{
    "dependencies": {
        "foo": "1.5.0",
        "bar": "~1.5.0",
        "qar": "^1.5.0",
        "zoo": "^1.5.0"
    }
}

五、Monorepo工具有哪些？

Monorepo 是一种代码管理策略，它将一个项目的所有代码存储在一个单独的版本控制库中。Monorepo 解决了多个问题：解决了代码共享与重复的困扰，提供更好的可追踪性和一致性。通过使用Monorepo，开发团队可以更好地组织、共享和管理代码，提高开发效率和协作质量。选择合适的Monorepo工具并灵活运用，能够帮助开发者更好地应对复杂的软件开发需求，推动项目的成功完成。

参考：

Hello Monorepo

2、使用情况：Vite 2.0 宣布使用 Esbuild 预构建依赖

3、为什么这么快？

（1）语言优势

大多数前端打包工具都是基于 JavaScript 实现的，而 Esbuild 则选择使用 Go 语言编写，两种语言各自有其擅长的场景，但是在资源打包这种 CPU 密集场景下，Go 更具性能优势。

虽然现代 JS 引擎与10年前相比有巨大的提升，但 JavaScript 本质上依然是一门解释型语言，JavaScript 程序每次执行都需要先由解释器一边将源码翻译成机器语言，一边调度执行；而 Go 是一种编译型语言，在编译阶段就已经将源码转译为机器码，启动时只需要直接执行这些机器码即可。也就意味着，Go 语言编写的程序比 JavaScript 少了一个动态解释的过程。

所以在编译运行层面，Go 前置了源码编译过程，相对 JavaScript 边解释边运行的方式有更高的执行性能。

（2）多线程优势

Go 天生具有多线程运行能力，而 JavaScript 本质上是一门单线程语言，直到引入 WebWorker 规范之后才有可能在浏览器、Node 中实现多线程操作。

我曾经研读过 Rollup、Webpack 的代码，就我熟知的范围内两者均未使用 WebWorker 提供的多线程能力。反观 Esbuild，它最核心的卖点就是性能，它的实现算法经过非常精心的设计，尽可能饱和地使用各个 CPU 核，特别是打包过程的解析、代码生成阶段已经实现完全并行处理。

JS 运行时概述

Node.js

Node.js 在 2023 年被 Stack Overflow 开发者评为最受欢迎的 Web 技术。Node.js 于 2009 年推出，允许开发人员在浏览器之外使用 JavaScript，彻底改变了服务端编程。它拥有强大的生态系统、庞大的社区，并且经过验证且稳定。为大型应用程序提供 LTS 构建。基于 V8 JavaScript 引擎构建。

多年来，Node.js 一直是服务端 JavaScript 开发的支柱，通过第三方工具支持了无数功能。其提供了巨大的功能和灵活性。丰富的文档、教程和社区支持使开发者可以更轻松地克服挑战。如果考虑内置工具和与 Web API 的兼容性，它是落后于其他两个运行时的。

从历史上看，Node.js 因其安全方法（尤其是在包方面）而受到批评。然而，社区和维护者已经显着改善了这一方面。权限模型已经在 Node.js v20 中实现，这使 Node.js 更加安全。

Deno

Deno 最初由 Node.js 的原始创建者 Ryan Dahl 于 2018 年创建，旨在解决他认为 Node.js 中存在的一些问题，比如性能、安全性。它专注于安全性、现代 JavaScript 实践和开发人员体验。基于 V8 JavaScript 引擎构建并用 Rust 编写。

与 Node.js 相比，Deno 具有更全面的功能。它对 Web API 和现代标准有很好的支持，并且还支持大多数 NPM 包。Deno 还提供了出色的开发体验，特别是如果使用 TypeScript，它是开箱即用的。Deno 还具有内置 linting、代码格式化程序等优势，节省一些配置和引导时间。如果你倾向于开箱即用的设置，只需启动编辑器，创建一个main.ts文件，然后就可以开始快乐编码了！

Bun

Bun 是 2021 年发布的 JavaScript 运行时，它被设计为 Node.js 的更快、更精简、更现代的替代品。它构建在 JavaScript Core 和 Zig 语言之上。旨在成为一个全功能的运行时环境和工具包，重点关注速度、打包、测试和与 Node.js 包的兼容性。最大的优势之一是它的性能。事实证明，Bun 比 Node.js 和 Deno 都要快。如果 Bun 能够完成这些目标，那么它将成为一个非常有吸引力的选择。Bun使用的是Apple的WebKit引擎，而不是像Node.js和其他运行时一样使用Google的V8引擎。

Bun 的核心卖点是它的性能，其提供了许多基准测试，显示出令人惊叹的速度。使用 Bun 作为包管理器比使用标准 NPM 命令要快得多。在现实应用中，尤其是 Web 应用，性能差异可能不像基准测试中那么显着。

Bun 优先考虑简单性和速度。凭借其内置的包管理器，以及与 Node.js 相比改进的开发体验，开发人员可以快速入门，而无需遇到其他运行时可能带来的初始设置障碍。

认识Bun

前言

Bun 不仅仅是一个运行时。它也是：

• 一个包管理器 (类似 Yarn、 NPM、 PNPM)
• 一个构建工具 (类似 Webpack、 ESBuild、 Parcel)
• 一个测试运行器
• …

Bun 还可以运行脚本。不管它做什么都比其他工具更快。Bun 在 JavaScript 生态系统的许多方面都有新的尝试，其中的重点是性能。它优先支持标准的 Web API，如 Fetch。它也支持许多 Node.js APIs，使其能与大多数 NPM 包兼容。

1、Bun是一个全能的工具包

JavaScript 的工具链在发展过程中，各种工具被逐渐添加进来，但没有一个统一的集中规划，导致工具链缺乏整体性和效率，变得运行缓慢和复杂。Bun的目标很简单，就是要消除JavaScript工具链的缓慢和复杂性。

为了实现这个目标，可能需要放弃一些在使用Bun之后变得不再必要的工具：

• Node.js：Bun 的一个可以直接替代的工具，因此不再需要以下工具：

• • node
  • npx：Bun 的 bunx 命令比 npx 快5倍。
  • nodemon：Bun 内置了监听模式，无需使用 nodemon。
  • dotenv、cross-env：Bun 默认支持读取.env文件的配置。

• 转译器：Bun 可以运行.js、.ts、``.cjs、.mjs、.jsx和.tsx文件，因此不再需要以下工具：

• • tsc：仍然可以保留它用于类型检查！
  • babel、.babelrc、@babel/preset-*：不再需要使用 Babel 进行转译。
  • ts-node、ts-node-esm：Bun 可以直接运行 TypeScript 文件。
  • tsx：Bun可以直接运行 TypeScript 的 JSX 文件。

• 构建工具：Bun 具有一流的性能和与esbuild兼容的插件API，因此不再需要以下工具：

• • esbuild
  • webpack
  • parcel, .parcelrc
  • rollup, rollup.config.js

• 包管理器：Bun 是一个与 npm 兼容的包管理器，可以使用熟悉的命令。它可以读取 package.json文件并将依赖写入node_modules目录，与其他包管理器的行为类似，因此可以替换以下工具：

• • npm, .npmrc, package-lock.json
  • yarn,yarn.lock
  • pnpm, pnpm.lock, pnpm-workspace.yaml
  • lern

• 测试库：Bun是一个支持Jest的测试运行器，具有快照测试、模拟和代码覆盖率等功能，因此不再需要以下测试相关的工具：

• • jest, jest.config.js
  • ts-jest, @swc/jest, babel-jest
  • jest-extended
  • vitest, vitest.config.ts

尽管这些工具都有自己的优点，但使用它们时往往需要将它们全部集成在一起，这会导致开发过程变得缓慢和复杂。而Bun通过成为一个单一的工具包，提供了最佳的开发者体验，从性能到API设计都力求做到最好。

2、Bun：JavaScript 运行时

（1）Bun内置了JavaScript转译器，因此可以运行JavaScript、TypeScript甚至JSX/TSX文件，无需任何依赖。因此，Bun的速度非常快，启动速度比 Node.js 快 4 倍。当运行TypeScript文件时，这种差异会更加明显，因为在Node.js中运行TypeScript文件需要先进行转译才能运行。

（2）Bun 同时支持ESM 和 CommonJS 这两种模块系统。无论是使用CommonJS的.js扩展名、.cjs扩展名，还是使用ES模块的.mjs扩展名，Bun都会进行正确的解析和执行，而无需额外的配置。

甚至可以在同一个文件中同时使用import和require()

（3）Bun 内置支持浏览器中可用的Web标准API，如fetch、Request、Response、WebSocket和ReadableStream等。开发者不再需要安装像node-fetch和ws这样的包。

3、Bun：包管理器

Bun的安装速度比 npm、yarn 和 pnpm 快好几个数量级。

4、Bun：测试运行器

5、Bun：构建工具

根据esbuild的基准测试，Bun比esbuild快1.75倍，比Parcel 2快150倍，比Rollup + Terser快180倍，比Webpack快220倍。

ES2020新特性是ECMAScript对应2020年的版本。通过babel中的babel-preset-es2020可以使用。

1、BigInt

（1）之前存在的问题

JavaScript 所有数字都保存成 64 位浮点数，这给数值的表示带来了两大限制。一是数值的精度只能到 53 个二进制位（相当于 16 个十进制位），大于这个范围的整数，JavaScript 是无法精确表示的，这使得 JavaScript 不适合进行科学和金融方面的精确计算。二是大于或等于2的1024次方的数值，JavaScript 无法表示，会返回Infinity。

1
2
3
4
5
6
7
8
9
10
11

// 1. 超过 53 个二进制位的数值，无法保持精度
Math.pow(2, 53) === Math.pow(2, 53) + 1 // true

// 2. 超过 2 的 1024 次方的数值，无法表示
Math.pow(2, 1024) // Infinity

// 3. 最大安全整数
let max = Number.MAX_SAFE_INTEGER;
let max1 = max + 1
let max2 = max + 2
max1 === max2   // true

（2）引入BigInt后

现在引入了一种新的数据类型 BigInt（大整数），来解决这个问题。BigInt 只用来表示整数，没有位数的限制，任何位数的整数都可以精确表示。

创建 BigInt 类型的值也非常简单，只需要在数字后面加上 n 即可。例如，123 变为 123n。也可以使用全局方法 BigInt(value) 转化，入参 value 为数字或数字字符串。

1
2
3
4
5
6

let max = BigInt(Number.MAX_SAFE_INTEGER);

let max1 = max + 1n
let max2 = max + 2n

max1 === max2   // false

（3）判断类型：

1
2
3

typeof 1n === 'bigint'; // true
typeof BigInt('1') === 'bigint'; // true
Object.prototype.toString.call(10n) === '[object BigInt]';    // true

（4）BigInt和Number不严格相等，但是宽松相等：

1
2

10n === 10 // false
10n == 10  // true

（5）Number和BigInt可以进行比较

1
2
3
4
5

1n < 2;    // true
2n > 1;    // true
2 > 2;     // false
2n > 2;    // false
2n >= 2;   // true

（6）如果算上 BigInt，JavaScript 中原始类型就从 6 个变为了 7 个。

• Boolean
• Null
• Undefined
• Number
• String
• Symbol (new in ECMAScript 2015)
• BigInt (new in ECMAScript 2019)

2、可选链操作符(?.)

1
2
3

a?.[x]
// 等同于
a == null ? undefined : a[x]

3、Promise.allSettled

Promise.allSettled跟Promise.all类似, 其参数接受一个Promise的数组, 返回一个新的Promise, 唯一的不同在于, 它不会进行短路, 也就是说当Promise全部处理完成后,我们可以拿到每个Promise的状态, 而不管是否处理成功。

4、Dynamic import

现在前端打包资源越来越大，前端应用初始化时根本不需要全部加载这些逻辑资源，为了首屏渲染速度更快，很多时候都是动态导入（按需加载）模块，比如懒加载图片等，这样可以帮助您提高应用程序的性能。

import()可以用于script脚本中，import(module) 函数可以在任何地方调用。它返回一个解析为模块对象的 promise。支持 await 关键字。

5、globalThis

globalThis 目的就是提供一种标准化方式访问全局对象，有了 globalThis 后，你可以在任意上下文，任意时刻都能获取到全局对象。

如果您在浏览器上，globalThis将为window，如果您在Node上，globalThis则将为global。因此，不再需要考虑不同的环境问题。

6、class的私有变量

最新提案之一是在类中添加私有变量的方法。我们将使用 # 符号表示类的私有变量。这样就不需要使用闭包来隐藏不想暴露给外界的私有变量。

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

class Counter {
  #x = 0;

  #increment() {
    this.#x++;
  }

  onClick() {
    this.#increment();
  }
}


const c = new Counter();
c.onClick(); // 正常
c.#increment(); // 报错

通过 # 修饰的成员变量或成员函数就成为了私有变量，如果试图在 Class 外部访问，则会抛出异常。

7、空值合并操作符（??）

我们在开发过程中，经常会遇到这样场景：变量如果是空值，则就使用默认值，我们是这样实现的：

1
2

let c = a ? a : b // 方式1
let c = a || b // 方式2

这两种方式有个明显的弊端，它都会覆盖所有的假值，如(0, ‘’, false)，这些值可能是在某些情况下有效的输入。

为了解决这个问题，有人提议创建一个nullish合并运算符，用 ?? 表示。有了它，我们仅在第一项为 null 或 undefined 时设置默认值。

8、class的static

它允许类拥有静态字段，类似于大多数OOP语言。静态字段可以用来代替枚举，也可以用于私有字段。

1
2
3
4
5
6
7
8
9
10
11

class Colors {
  // public static 字段
  static red = '#ff0000';
  static green = '#00ff00';

  // private static 字段
  static #secretColor = '#f0f0f0';
}

font.color = Colors.red;
font.color = Colors.#secretColor; // 出错

9、String.prototype.matchAll

matchAll() 是新增的字符串方法，它返回一个包含所有匹配正则表达式的结果及分组捕获组的迭代器。因为返回的是遍历器，所以通常使用for...of循环取出。

1
2
3
4
5

for (const match of 'abcabc'.matchAll(/a/g)) {
    console.log(match)
}
//["a", index: 0, input: "abcabc", groups: undefined]
//["a", index: 3, input: "abcabc", groups: undefined]

需要注意，该方法的第一个参数是一个正则表达式对象，如果传的参数不是一个正则表达式对象，则会隐式地使用 new RegExp(obj) 将其转换为一个 RegExp 。另外，RegExp必须是设置了全局模式g的形式，否则会抛出异常 TypeError。

和match()的区别就在于match()只返回匹配到的对应的值。

二、ES12新特性（2021）

2021年3月13日，ES2021 候选提案发布了其最终功能集的版本。如果它能够在今年6月的ECMA 大会上通过，就会成为官方的标准！

这个候选提案提及到ECMAScript新特性如下所示：

• String.prototype.replaceAll()
• Promise.any
• 逻辑运算符和赋值表达式
• 数值分隔符
• WeakRef and Finalizers

这些新的特性已经进入第四阶段且已添加到谷歌 Chrome V8 引擎中。接下来我们来介绍下这些ES2021的新特性吧。

1、replaceAll()

1
2
3

let string = 'hello world, hello ES12'
string.replace(/hello/g,'hi')    // hi world, hi ES12
string.replaceAll('hello','hi')  // hi world, hi ES12

是对replace的扩充。注意：replaceAll在使用正则表达式的时候，如果非全局匹配(/g)，会抛出异常：

1
2
3
4

let string = 'hello world, hello ES12'
string.replaceAll(/hello/,'hi')

// Uncaught TypeError: String.prototype.replaceAll called with a non-global

2、Promise.any()

在 ES6 中引入了 Promise.race() 和 Promise.all() 方法，ES2020 加入了 Promise.allSettled()。 ES2021 又增加了一个使 Promise 处理更加容易的方法：Promise.any()

Promise.any() 接收一个Promise可迭代对象，只要其中的一个 promise 成功，就返回那个已经成功的 promise 。如果可迭代对象中没有一个 promise 成功（即所有的 promise 都失败/拒绝），就返回一个失败的 promise 和AggregateError类型的实例，它是 Error的一个子类，用于把单一的错误集合在一起。

Promise.any()跟Promise.race()方法很像，只有一点不同，就是不会因为某个 Promise 变成rejected状态而结束。

3、逻辑赋值操作符（&&=, ||=, ??=）

1
2
3
4

var x = 1;
var y = 2;
x &&= y; // 等价于 x && (x=y)
console.log(x); // 2

4、数字分隔符

我们将通过使用_（下划线）字符在数字组之间提供分隔，使读取数值更加容易，提高可读性。

1

let x = 100_000; // 100000

5、WeakRef and Finalizers

此功能包含两个高级对象 WeakRef 和 FinalizationRegistry。根据使用情况，这些接口可以单独使用，也可以一起使用。官方建议不要轻易使用 WeakRef 和 finalizer。其中一个原因是它们可能不可预测，另一个是它们并没有真正帮 gc 完成工作，实际上可能会垃圾回收的工作更加困难。

在 JavaScript 中，当你创建了一个创建对象的引用时，这个引用可以防止对象被垃圾收集，也就是说 JavaScript 无法删除对象并释放其内存。只要对该对象的引用一直存在，就可以使这个对象永远存在。

ES2021 添加了新的类 WeakRefs。允许创建对象的弱引用。这样就能够在跟踪现有对象时不会阻止对其进行垃圾回收。对于缓存和对象映射非常有用。

必须用 new关键字创建新的 WeakRef ，并把某些对象作为参数放入括号中。当你想读取引用（被引用的对象）时，可以通过在弱引用上调用 deref() 来实现。

1
2
3
4
5
6
7
8
9
10

const myWeakRef = new WeakRef({
  name: '星野',
  year: '25'
})

myWeakRef.deref()
// => {  name: '星野', year: '25' }

myWeakRef.deref().name
// => '星野'

与 WeakRef 紧密相连的还有另一个功能，名为 finalizers 或 FinalizationRegistry。这个功能允许你注册一个回调函数，这个回调函数将会在对象被垃圾回收时调用。

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

// 创建 FinalizationRegistry:
const reg = new FinalizationRegistry((val) => {
  console.log(val)
})


(() => {
  // 创建新对象:
  const obj = {}

  //为 “obj” 对象注册 finalizer：
  //第一个参数：要为其注册 finalizer 的对象。
  //第二个参数：上面定义的回调函数的值。
  reg.register(obj, 'obj has been garbage-collected.')
})()
// 当 "obj" 被垃圾回收时输出：
// 'obj has been garbage-collected.'

总而言之，JavaScript 中对象的引用是强引用，WeakMap 和 WeakSet 可以提供部分的弱引用功能，若想在 JavaScript 中实现真正的弱引用，可以通过配合使用 WeakRef 和终结器（Finalizer）来实现。

三、ES13新特性（2022）

1、Object.hasOwn()

在ES2022之前，可以使用 Object.prototype.hasOwnProperty() 来检查一个属性是否属于对象。

Object.hasOwn 特性是一种更简洁、更可靠的检查属性是否直接设置在对象上的方法：

1
2
3
4
5
6
7

const example = {
  property: '123'
};


console.log(Object.prototype.hasOwnProperty.call(example, 'property'));
console.log(Object.hasOwn(example, 'property'));

2、通过at()来对字符串或数组进行索引

1
2
3
4
5
6
7

const array = [0,1,2,3,4,5];

console.log(array[array.length-1]);  // 5
console.log(array.at(-1));  // 5

console.log(array[array.lenght-2]);  // 4
console.log(array.at(-2));  // 4

1
2
3
4

const str = "hello world";

console.log(str[str.length - 1]);  // d
console.log(str.at(-1));  // d

3、error.cause

在ES13中，new Error()中可以指定导致它的原因：

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

function readFiles(filePaths) {
  return filePaths.map(
    (filePath) => {
      try {
        // ···
      } catch (error) {
        throw new Error(
          `While processing ${filePath}`,
          {cause: error}
        );
      }
    });
}

4、Top-level await

ES2017（ES8）中的 async/await特性仅仅允许在 async 函数内使用 await 关键字，新的提案旨在允许 await 关键字在顶层内容中的使用，例如可以简化动态模块加载的过程：

1

const strings = await import(`/i18n/${navigator.language}`);

这个特性在浏览器控制台中调试异步内容（如 fetch）非常有用，而无需将其包装到异步函数中。

另一个使用场景是，可以在以异步方式初始化的 ES 模块的顶层使用它(比如建立数据库连接)。当导入这样的“异步模块”时，模块系统将等待它被解析，然后再执行依赖它的模块。这种处理异步初始化方式比当前返回一个初始化promise并等待它解决来得更容易。一个模块不知道它的依赖是否异步。

1
2
3
4
5
6

// db.mjs
export const connection = await createConnection();

// server.mjs
import { connection } from './db.mjs';
server.start();

在此示例中，在server.mjs中完成连接之前不会执行任何操作db.mjs。

顶级await在以下场景中将非常有用：

• 动态加载模块

  1	const strings = await import(`/i18n/${navigator.language}`);

• 资源初始化

  1	const connection = await dbConnector();

• 依赖回退

  1 2 3 4 5 6

  let translations; try { translations = await import('https://app.fr.json'); } catch { translations = await import('https://fallback.en.json'); }

5、正则表达式匹配索引

（1）该特性允许我们利用 d 字符来表示我们想要匹配字符串的开始和结束索引。以前，只能在字符串匹配操作期间获得一个包含提取的字符串和索引信息的数组。在某些情况下，这是不够的。因此，在这个规范中，如果设置标志 /d，将额外获得一个带有开始和结束索引的数组。

1
2
3
4

const matchObj = /(a+)(b+)/d.exec('aaaabb');

console.log(matchObj[1]) // 'aaaa'
console.log(matchObj[2]) // 'bb'

（2）由于 /d 标识的存在，matchObj还有一个属性.indices，它用来记录捕获的每个编号组：

1
2

console.log(matchObj.indices[1])  // [0, 4]
console.log(matchObj.indices[2])  // [4, 6]

（3）我们还可以使用命名组：

这里给两个字符匹配分别命名为as和bs，然后就可以通过groups来获取到这两个命名分别匹配到的字符串。

它们的索引存储在 matchObj.indices.groups 中：

1
2

console.log(matchObj.indices.groups.as);  // [0, 4]
console.log(matchObj.indices.groups.bs);  // [4, 6]

匹配索引的一个重要用途就是指向语法错误所在位置的解析器。

1. 进入Oracle官网下载页面

https://www.oracle.com/cn/downloads/

1

补充：首次下载可能需要注册/登录用户

2. 选择Database，点击数据库企业标准版

3. 选择Oracle Database Free，点击Select your download below，进入下载页

4. 选择适合自己电脑操作系统的版本，点击zip进行下载

二、数据库安装

1. 解压zip并运行setup.exe

将下载的zip文件解压到一个目录下，该目录最好使用纯英文字符进行命名。并且该目录需要长期存在，即使在Oracle安装成功后也不能删除。然后以管理员身份运行setup.exe。

2. 创建并配置单实例数据库

3. 错误：无权限或空间不足错

点击下一步有可能会提示“无法创建目录AppData\Local\Temp，无权限或空间不足”的错误。原因可能是因为原来的环境变量temp和tmp配置目录存在数字或其他特殊字符导致。
解决方法：修改temp环境变量。右键开始菜单–系统–高级系统设置–高级–环境变量，找到temp和tmp变量，统一将其目录指向到新的临时目录，如：d:\temp。

4. 系统选择桌面类

5. 使用Windows内置账户

6. 自定义选择安装路径，全局数据库名称，数据库登录口令

7. 错误：已存在具有指定标识符的数据库实例

点击下一步如果提示：“[INS-35075] 已存在具有指定标识符的数据库实例”。是因为之前安装过Oracle，没有清除干净。

解决方法：

（1）任务管理器右击，选择服务页面，打开服务，停止Oracle相关服务
（2）运行regedit，选择HKEY_LOCAL_MACHINE > SOFTWARE > ORACLE，按del键删除这个入口
（3）运行regedit，选择HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services，滚动这个列表，删除所有Oracle入口

注意：卸载并清除Oracle后需要重启电脑才会生效。

8. 安装

9. 错误：[INS-20802] Oracle Database Configuration Assistant 失败。

安装过程中可能会出现：[INS-20802] Oracle Database Configuration Assistant 失败。

解决方法：

（1）以管理员身份运行 D:\\OracleHome 下 BIN 目录中的 netca.bat

（2）选第一个“监听程序配置”添加：不成功，提示已经运行。那么选择 监听程序配置“重新配置”，配置成功，然后在oracle安装页面重试即可。

10. 安装完成

三、数据库验证

cmd进入终端，输入sqlplus，提示输入用户名，口令（默认用户名：system，口令：数据库安装时输入的口令），点击回车，进入数据库输入列，则此时数据库安装完成。

运用sql Developer连接Oracle时：
​ 用户名：system
​ 口令：数据库安装时输入的口令
​ SID：orcl
​ 若提示：Listener refused the connection with the following error: ORA-12505, TNS:listener does not currently know of SID given in connect descriptor 错误，则：
需要找到解压文件\network\admin内的tnsnames.ora文件，将SERVER的值修改为orcl

我很好奇地问，你要学什么？

这个读者回答，他要学习企业管理。

如果你真是为了学到点什么，是为了学习企业管理，那无论是宝总还是宋厂长，都是带着滤镜的。你通过他们，只能欣赏影视剧，不可能学到点什么。

因为传播学的基本概念就是足够简单。任何东西一旦复杂了，需要思考了，就没法传播了。

前些天有好几个读者留言，说美国之所以无法禁枪的真正原因，是枪支军火集团为了他们的利益。

这个说法对不对？

当然是对的。

但是有没有意义？

没有。

任何绝对正确的东西，都没有信息含量的。

两个南方人，讨论兰州，说兰州之所以满大街牛肉面，是因为兰州牛肉利益集团的存在。

这句话对不对？

太对了，所以我说是废话。

如果你因为悟到了这么句废话，就以为自己掌握了真理，跑去兰州创业，卖猪肉面，指望自己变成兰州的猪肉利益集团。

你会亏得连姥姥都不认得。而且破产前还会仰天痛哭，为什么牛肉利益集团能做到的，我猪肉利益集团就不行呢…….

网民的智慧也是智慧，你能看到美国的枪支利益集团，能看到兰州的牛肉利益集团，恭喜你，你在网民里已经算聪明的了。

但这种聪明，也就看看电影电视剧行。现实生活中，没啥用的。

就像咱们读者问两部电视剧哪部能学习？

哪部也不值得学习。

因为任何时候，人们都不会就当时发生的事情进行深刻地讨论，这是做不到的。

你不会和你的儿子深刻地剖析自己，不会剖析你的爸爸，不会剖析你的爷爷，不会的。

你有可能深刻剖析的，是隔壁老王家的爷爷。

明白我这意思么？

你的孩子如果要理解深刻的东西，是不可能通过你来做到的，他得通过隔壁老王。

所以如果你要学企业管理，你不用看这些，这些一定是用来消遣的，你只能去看隔壁老王。

比如，你可以看看日本的明治维新。

你不用去看日本的史料或者怎么怎么样，不需要的，你只要看我们作为邻居对日本明治维新的研究，就已经足够深刻了，已经足够你成长了。

日本的明治维新是说明治天皇要学欧美，然后一个农业国就转成工业国了？可不可能上下齐心这么简单一句话？

这种只是讲过程，一个过程的发生，一定是伴随着复杂的利益分配，以及各种团体的兴起。

明治要维新，第一件事就是动蛋糕，动了谁的蛋糕？动了整个武士阶层，包括各地藩主的蛋糕。

日本的农民是把粮食上交大名的，大名再分配给武士，于是武士和大名之间有人身依附关系。

各地的藩主大名和德川幕府之间也有人身依附关系，这是一个社会结构。

现在要打破过去的社会结构，就意味着藩主大名没有办法直接征收粮食，矿产，同时也意味着武士阶层集体下岗。

那这显然不是一句话的事情，兰州的牛肉利益集团也不是一句话就兴起了。

确切地说，是日本州岛西部以及九州岛的那些武士们，集体留洋，考察英美俄德各个国家，最后企图制定一套新的游戏制度。

那么这套新游戏下，谁说了算？谁留洋谁说了算，谁留洋谁被重新任命为管理层。而过去的传统武士，就会失业。

所以这是利益冲突，留洋武士和没留洋武士之间的冲突，大家争的是话语权。

最后的结果是战争，你看到很多漫画，描述明治维新时期武士，浪人斩的内容，这些都是在讲述那个时代的矛盾冲突。

打完了之后，拥有武器的留洋派控制了日本，整个武士阶层消失，大家被迫转型，要么去经商，成为后来的三井三菱财阀社团，要么去从政，进入文官体系。

在这个阶段，日本的下层是一无所知的。

种地的还是种地，他根本不会理解什么维新不维新，他无非当初粮食交给藩主大名，现在藩主大名没有了，粮食直接上缴。

在这个过程中，日本农民的负担更重了，因为两个需要。

一个是需要工业化筹措启动资金，无论是留洋武士还是传统武士，他们都不事生产，财富只能取自农民。

另一个是为工业化筹措劳动力，俗称失地农民，农民失去了土地，自然会转化成工厂的劳动力。

俗称出钱是你，出力的还是你。

这两件事都OK了，明治维新才开启马达，然后就是你知道的，日本人开始发动侵略了，无论对大清还是日俄战争。

俗称明治维新的本质就是先达成一致，然后让农民出钱，农民出力，最后农民亲自当兵，到处打打打。

这个过程，你通过了解明治维新的过程是可以初步理解创业的，如果你要做总经理的话。

你开一家公司，不可能是为了员工如何如何，虽然马云都是这么讲，员工第一，顾客第二，资方第三。

但实际上真正执行的时候，不是这样的。

如果你去看繁花，或者看大江大河，你很容易把做生意理解成过家家。

宝总的朋友很多，女朋友也很多，他人也很仗义，今天帮帮张三，明天帮帮李四，后天张三李四都帮他。

所谓的商战就是宝总带着一群人，去打对方带着一群人。

但实际上，你通过了解明治维新也会清楚，日俄战争开打之前，日本自己走过多少路。

首先要明确一件事，就是往哪儿走。

我要做什么。

知道自己这家初创公司要做什么比具体怎么做更重要。

为此日本派出了过半的精英，去各个先发的工业国考察，去研究人家是怎么做的，以及哪部分自己可以抄，哪部分要改良要本土化。

那么接下来第二步就是怎么达成一致。

很多富二代接班失败，被媒体嘲笑成个人能力不足，实际上跟个人能力毛线关系都没有。

一家公司能够形成，能够运营，它一定是达成了某种平衡的。

日本存在了那么多年，一定有它的道理，农民交租给藩主大名，藩主大名给武士发工资，这种现存的结构就是平衡。

你要打破这种平衡，就得形成新平衡。

你动了别人的蛋糕可以，但是你动完蛋糕之后，一定是要达成新的分配方案的。

李自成为什么注定失败？从第一阶段就注定了。

闯王来了不纳粮，这就意味着他是一盘散沙。既然不纳粮，那组织结构怎么形成？没有组织结构，你怎么征召兵员呢？都靠个人主观能动性么？

那么你看我，我看你，都不主动，李自成焉能不败。

所以明治维新绝对不是说今年你不给武士纳粮了，明天你就吃饱了，你想太美了，没那好事儿。

创业也是一样的，你永远不可能拿出一个方案大家都满意，资方满意，客户满意，员工满意，这是不可能的。

你只能拿出一个方案，让大家都误以为自己会是那个被满意的。

明白不？误以为。

误以为，才有积极性，不满意，才有积极性。

一定要明白这个道理，都对现状满意了，就没有积极性了，公司也就不可能前进了。

人只有对现状不满，又误以为未来会满意，才会有动力。

一个优秀的企业家，一定是理解这个粗浅道理的。

你才能驾驭着资方，员工，客户，在不平衡的过程中又勉强维持平衡，你需要不平衡来产生动力，你需要平衡来做刹车，开车不能只有油门没有刹车。

所以我说，如果你对当老板这么感兴趣，随便找点啥做参照物都能明白，无论是隔壁老张还是隔壁老王。

唯独不要靠电视剧，包括所谓神剧，那些是消遣娱乐的。

快速上手

1. 新建目录并初始化(我的目录名为kittydocs)

这里我们使用pnpm式，当然yarn，npm都是可以的,如果你没有安装pnpm可以全局安装

1

npm i pnpm -g

然后初始化

1

pnpm init

2. 安装vitepress

1

pnpm i vitepress

3. package.json添加script

1
2
3
4
5

"scripts": {
   "docs:dev": "vitepress dev docs",
   "docs:build": "vitepress build docs",
   "docs:serve": "vitepress serve docs"
 }

这三个脚本分别代表启动本地文档服务，打包文档，启动打包后（dist）服务

4. 创建文档 文档放在docs目录下，新建docs/index.md

1

## hello juejin

此时我们的文件结构为

1
2
3
4

.
├─ docs 
│  └─ index.md
└─ package.json

5. 启动本地服务文档站点

1

pnpm run docs:dev

此时便会启动一个http://localhost:3000/ 的服务,默认加载docs/index.md

到这里一个简单的站点就完成了，当然这肯定是不够的，接下来我们看vitepress的配置

配置文件

在docs目录下创建一个 .vuepress目录，如下结构

1
2
3
4
5
6

.
├─ docs
│  ├─ .vitepress
│  │  └─ config.js
│  └─ index.md
└─ package.json

config.js导出一个js对象

1
2
3
4

export default {
    title: 'kittyui', //站点标题
    description: '一个vue3组件库',//mate标签description，多用于搜索引擎抓取摘要
  }

此时我们重启服务便可看到

导航栏

1. title和logo

首先看一下title和logo的配置

1
2
3
4
5
6

export default {
  themeConfig: {
    siteTitle: "Kitty",
    logo: "/logo.png",
  },
};

其中logo的地址对应的是public下的图片，目录结构如下所示

1
2
3
4
5
6
7
8

.
├─ docs
│  ├─ .vitepress
│  │  └─ config.js
│  ├─ public
│  │   └─ logo.png
│  └─ index.md
└─ package.json

这里logo我是用了vue的图标，此时页面效果为

2. 右侧导航

我们可以在themeConfig.nav配置右侧导航,并且点击可以跳转我们指定页面。

1
2
3
4
5
6
7
8
9

themeConfig: {
  siteTitle: "Kitty",
  logo: "/logo.png",
  nav: [
    { text: "Guide", link: "/guide/" },
    { text: "GuideTest", link: "/guide/test" },
    { text: "gitee", link: "https://gitee.com/geeksdidi" },
  ],
}

同时我们在docs下新建guide/index.md和test.md

1

# guild

1

# test

此时我们页面即可展示我们打nva并且支持了跳转本地markdown文件以及外部链接

我们还可以这样嵌套配置，使得导航栏出现下拉选项

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

themeConfig: {
    siteTitle: "Kitty",
    logo: "/logo.png",
    nav: [
      { text: "Guide", link: "/guide/" },
      { text: "GuideTest", link: "/guide/test" },
      { text: "gitee", link: "https://gitee.com/geeksdidi" },
      {
        text: "Drop Menu",
        items: [
          { text: 'Item A', link: '/item-1' },
          { text: 'Item B', link: '/item-2' },
          { text: 'Item C', link: '/item-3' }
        ]
      }
    ]
  }

如果我们想要让下拉选项分组，即中间有条分割线，我们的nav可以这样写

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

nav: [
     { text: "Guide", link: "/guide/" },
     { text: "GuideTest", link: "/guide/test" },
     { text: "gitee", link: "https://gitee.com/geeksdidi" },
     {
       text: "Drop Menu",
       items: [
         {
           items: [
             { text: "Item A1", link: "/item-A1" },
             { text: "Item A2", link: "/item-A2" },
           ],
         },
         {
           items: [
             { text: "Item B1", link: "/item-B1" },
             { text: "Item B2", link: "/item-B2" },
           ],
         },
       ],
     },
   ]

此时效果为

配置社交链接socialLinks

使用themeConfig.socialLinks可以配置我们的社交链接，目前支持的有

1
2
3
4
5
6
7
8
9
10

type SocialLinkIcon =
  | 'discord'
  | 'facebook'
  | 'github'
  | 'instagram'
  | 'linkedin'
  | 'slack'
  | 'twitter'
  | 'youtube'
  | { svg: string }

配置如下

1
2
3
4
5
6
7
8
9
10
11

socialLinks: [
      { icon: "github", link: "https://gitee.com/geeksdidi" },
      { icon: "twitter", link: "..." },
      // You can also add custom icons by passing SVG as string:
      {
        icon: {
          svg: '<svg role="img" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"><title>Dribbble</title><path d="M12...6.38z"/></svg>',
        },
        link: "...",
      },
    ],

侧边栏Sidebar

侧边栏可以在themeConfig.Sidebar中配置，其实和nav配置差不多

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

sidebar: [
  {
    text: "组件库源码实现",
    items: [
      {
        text: "组件库环境搭建",
        link: "/articles/组件库环境搭建",
      },
      { text: "gulp的使用", link: "/articles/gulp的使用" },
    ],
  },
  {
    text: "vue教程",
    items: [
      {
        text: "pina和vuex",
        link: "/articles/pina和vuex",
      },
    ],
  },
],

这里我搬运了我掘金上的一些文章放了进去，目录结构如下图

页面展示效果如下

不过我们一般不会使用这种方式配置侧边栏，因为这样每个页面都会有侧边栏。我们需要做到仅某些页面才会出现侧边栏。所以我们可以这样配置

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

sidebar: {
  "/articles/": [
    {
      text: "组件库源码实现",
      items: [
        {
          text: "组件库环境搭建",
          link: "/articles/组件库环境搭建",
        },
        { text: "gulp的使用", link: "/articles/gulp的使用" },
      ],
    },
    {
      text: "vue教程",
      items: [
        {
          text: "pina和vuex",
          link: "/articles/pina和vuex",
        },
      ],
    },
  ],
},

sideBar值改成一个对象，对象的key是一个路径，只有包含这个路径的才会出现侧边栏。所以我们将nav的配置中的guild改成博客，同时路径指向我们的articles下的markdown文件

1
2
3

nav: [
      { text: "博客", link: "/articles/组件库环境搭建" },
     ]

此时你会发现进入首页并不会出现sideBar，只有点击博客才会出现侧边栏

配置可折叠侧边栏

配置可折叠侧边栏只需将collapsible设置为true即可,默认初始页面是全部展开页面，如果你需要关闭状态只需要将collapsed设置为true

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

...
        {
          text: "vue教程",
          collapsible: true,
          collapsed:true,
          items: [
            {
              text: "pina和vuex",
              link: "/articles/pina和vuex",
            },
          ],
        },
...

首页布局

首页就是进入我们博客会加载docs/index.md,所以我们需要对其进行一个美化，我们VitePress默认主题提供了一个主页布局

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

---
layout: home

hero:
  name: 东方小月的博客
  text: 随便写点啥.
  tagline: 帅气又迷人的小月
  image:
    src: /logo.png
    alt: Kitty
  actions:
    - theme: brand
      text: 快来快来
      link: /articles/组件库环境搭建
    - theme: alt
      text: View on Gitee
      link: https://gitee.com/geeksdidi

features:
  - icon: ⚡️
    title: 这是一个闪电图标
    details: wawawa
  - icon: 🖖
    title: 这是一个手掌图标
    details: good...
  - icon: 🛠️
    title: 这是一个修理图标
    details: cocococo
---

部署到GitHub Pages

1. 新建github仓库

既然要部署到GitHub Pages，你得先在github新建一个仓库，因为要用他的GitHub Pages，所以仓库命名为username.github.io的形式，username是你github的用户名。然后点击设置

选择pages

这里设置根目录/(root),当然也可以选择其它目录,点击保存，如果选择其它目录比如docs，config.js就需要配置一个base

1
2
3

export default {
    base:'/docs/'
  }

最后选择一个主题(这里不选择我发现站点不生效,后面把打包后的代码推上来即可,会默认加载index.html)

2. 通过 deploy.sh 部署

然后将打包后的dist下的文件推送到你的远程仓库。vitepress官网给我们提供了一个脚本文件deploy.sh，我们只需要改下远程仓库即可

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

#!/usr/bin/env sh

# 忽略错误
set -e

# 构建
npm run docs:build

# 进入待发布的目录
cd docs/.vitepress/dist

# 如果是发布到自定义域名
# echo 'www.example.com' > CNAME

git init
git add -A
git commit -m 'deploy'

# 如果部署到 https://<USERNAME>.github.io
# git push -f git@github.com:<USERNAME>/<USERNAME>.github.io.git master

# 如果是部署到 https://<USERNAME>.github.io/<REPO>
# git push -f git@github.com:<USERNAME>/<REPO>.git master:gh-pages

cd -

直接执行这个脚本文件，我们的打包后的文件就会被推送到我们的仓库。然后我们就可以直接访问我们的静态博客站点了，如果你想要自定义其它域名的话,可以创建一个组织然后在组织下新建仓库名为organization.github.io的形式(organization是你组织名)然后执行同样的操作即可。具体可以点这里创建 GitHub Pages 站点

3. 通过Windows系统下使用的脚本文件部署

上一步我们上传的仅仅是工程的源代码。还需要上传构建成果，才能发布博客网站。我们在工程根目录创建文件bin/autoDeploy.bat，这是一个Windows系统下使用的脚本文件。

1
2
3
4
5
6
7
8

call pnpm docs:build
cd docs/.vitepress/dist

git init
git add -A
git commit -m "auto construct blog"

git push -f https://github.com/jzplp/jzplp.github.io.git master:gh-pages

注意里面的push地址需要改成你自己的。

文件内容即是我们的构建和发布流程： 1. 构建工程，生成dist，并进入dist目录。 2. 将dist目录中的内容上传至gh-pages分支中。

如果使用非Windows系统，对该脚本文件后缀名和内容进行适当修改即可。

我们在package.json的scripts中增加一条命令：

1

"deploy:win": "powershell bin/autoDeploy.bat"

此时可以执行这条命令，即可完成dist构建包的上传。

1

pnpm deploy:win

4. 使用GitHub Actions进行自动构建和发布

使用上面描述的方法，我们每次写完博客，提交工程代码后，还需要手动构建，更新分支并发布。

那么有没有方法让每次提交工程代码后，自动构建并发布呢？我们使用GitHub Actions就能做到这一点。而且GitHub还提供了服务器，我们可以把构建过程放到服务器中进行。

首先创建配置文件，位置.github/workflows/deploy.yml。

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

name: algolia
on: 
  push:  # 有代码push或者merge到main分支时，才进行下面的操作
    branches: 
      - main
jobs:
  deploy:
    runs-on: ubuntu-latest 
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Install Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 16

      - uses: pnpm/action-setup@v2  # 配置使用pnpm
        name: Install pnpm
        id: pnpm-install
        with:
          version: 8
          run_install: false
      
      - name: Get pnpm store directory
        id: pnpm-cache
        shell: bash
        run: |
          echo "STORE_PATH=$(pnpm store path)" >> $GITHUB_OUTPUT

      - uses: actions/cache@v3
        name: Setup pnpm cache
        with:
          path: ${{ steps.pnpm-cache.outputs.STORE_PATH }}
          key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
          restore-keys: |
            ${{ runner.os }}-pnpm-store-

      - name: Install dependencies
        run: pnpm install

      - name: Build docs
        run: pnpm run docs:build

      - name: Deploy Files on Ftp Server
        uses: SamKirkland/FTP-Deploy-Action@4.3.3
        with:
         server: '' # FTP服务器地址
         username: '' # FTP用户名
         password: '' # FTP密码
         local-dir: ./docs/.vitepress/dist/ #需要发布内容的路径
         server-dir: ./wwwroot/
         protocol: ftp
         port: 21

GitHub Actions的环境中提供了很多预置的配置和工具，例如Node.js，pnpm等等，我们直接使用即可。如果你的配置和文中上述流程一致，那么直接复制该文件内容到你的工程即可。之后上传到工程代码GitHub仓库中。如果想了解更多，可以参考GitHub Actions文档以及其他人的配置。

当然，你如果没有自己的FTP服务器，希望自动部署到Github Pages，配置方法参考：使用Github Action实现全自动部署

1. 什么是微前端

微前端提供了一种技术：可以将多个独立的Web应用聚合到一起，提供统一的访问入口。一个微前端应用给用户的感观就是一个完整的应用，但从技术角度上来讲它是由一个个独立的、通过某种方式组合而成的应用。

2. 微前端的特点

目前的微前端框架一般都具有以下三个特点：

（1）技术栈无关：主框架不限制接入应用的技术栈，子应用具备完全自主权。

（2）独立性强：独立开发、独立部署，子应用仓库独立。

（3）状态隔离：运行时每个子应用之间状态隔离。

3. 微前端发展历史

（1）2014年：Martin Fowler和James Lewis共同提出了微服务的概念。微服务的主要思路是将应用分解为小的、互相连接的独立服务，每个微服务完成某个特定功能；每个微服务都有自己的业务逻辑和适配器，不同的微服务可以使用不同的技术去实现，最后使用统一的网关进行调用。

（2）2016年：Micro frontend一词首次出现在ThoughtWorks Technology Radar上。它将微服务的概念扩展到前端世界，简称其为微前端。

（3）2018年：第一个微前端工具single-spa在github上开源。

（4）2019年：基于single-spa的qiankun问世。

（5）2020年：Module Federation(webpack5)把项目中模块分为本地模块和远程模块，远程模块不属于当前构建。当使用远程模块时，这些异步操作将被放置在远程模块和入口之间的下一个chunk的加载操作中，从而实现微前端的构建。

（6）2021年：基于 WebComponent 的 micro-app 问世。

（7）2022年：基于 Web Components + iframe 微前端框架无界（wujie）问世。

4. 如何判断自己的项目需要使用微前端？

（1）项目功能逐渐增多，代码规模庞大，导致代码维护和开发效率低下；

（2）项目需要集成多个不同技术栈的模块或服务；

（3）团队成员分散，各自负责开发不同的模块或服务，需要实现独立开发和部署；

（4）项目需要支持独立的生命周期管理和版本控制；

（5）需要实现高可用性和弹性伸缩；

（6）需要实现动态加载和卸载子应用等场景。

所以呢，觉得如果项目具有上面这些特点，那么可以考虑使用微前端来优化项目架构和提升开发效率。

微前端框架

1. iframe

（1）为iframe正名

任何新技术、新产品都是有一定适用场景的，它可能在当下很流行，但它不一定在任何时候都是最优解。

最近几年微前端很火，火到有时候项目里面用到了iframe还要偷偷摸摸地藏起来生怕被别人知道了，因为担心被人质疑：你为什么不用微前端方案？直到最近笔者接手一个项目，需要将现有的一个系统整体嵌入到另外一个系统（一共20多个页面），在被微前端坑了几次之后，回过头发现，iframe真香！

诚然iframe确实存在很多缺点，但是在选择一个方案的时候还是要具体场景具体分析，它可能在当下很流行，但它不一定在任何时候都是最优解：iframe的这些缺点对我来说是否能够接受？它的缺点是否有其它方法可以弥补？使用它到底是利大于弊还是弊大于利？我们需要在优缺点之间找到一个平衡。

（2）优缺点分析

（3）iframe适合的场景

由于iframe的一些限制，部分场景并不适合用iframe，比如像下面这种iframe只占据页面中间部分区域，由于父页面已经有一个滚动条了，为了避免出现双滚动条，只能动态计算iframe的内容高度赋值给iframe，使得iframe高度完全撑满，但这样带来的问题是弹窗很难处理，如果居中的话一般弹窗都相对的是iframe内容高度而不是屏幕高度，从而导致弹窗可能看不见，如果固定弹窗top又会导致弹窗跟随页面滚动，而且稍有不慎iframe内容高度计算有一点点偏差就会出现双滚动条。

所以：

• 如果页面本身比较简单，是一个没有弹窗、浮层、高度也是固定的纯信息展示页的话，用iframe一般没什么问题；

• 如果页面是包含弹窗、信息提示、或者高度不是固定的话，需要看iframe是否占据了全部的内容区域，如果是像下图这种经典的导航+菜单+内容结构、并且整个内容区域都是iframe，那么可以放心大胆地尝试iframe，否则，需要慎重考虑方案选型。

为什么一定要满足“iframe占据全部内容区域”这个条件呢？可以想象一下下面这种场景，滚动条出现在页面中间应该大部分人都无法接受：

（4）利用 iframe 实现微前端实战

iframe 实现微前端

2. single-spa

single-spa是第一个微前端框架，当前流行的大量框架都是single-spa的上层封装，但是如果作为生产选型，single-spa提供的是较为基础的api，应用在实际项目中需要进行大量封装且入侵性强，使用起来不太方便。但是如果想学习相关技术或者封装一套更灵活的解决方法还是很值得使用的。

如果想了解更多关于single-spa，请查看：微前端（single-spa）简介

3. qiankun

qiankun是阿里开源的一套框架，基于single-spa的上层封装，社区活跃度较高，在国内的生态较好，中文文档齐全，有大量的先行者铺路，比较适合用于生产环境。

（1）运行原理

qiankun 和 single-spa最大的不同，在于single-spa 是基于JS Entry，即通过某一地址引入JS文件来加载整个子应用。 而 qiankun是通过 HTML Entry，规避了JavaScript为了支持缓存而根据文件内容动态生成文件名，造成入口文件无法锁定的问题。

在qiankun中，当我们拿到了子应用的 HTML 文本时，我们不能直接通过 container.innerHTML = html 方式将文本放到容器内，这样是无法显示的。

原因是浏览器出于安全考虑，放到页面上的 HTML 如果包含了 JS 脚本，它是不会去执行的。所以我们需要手动处理 script 脚本，qiankun是通过 import-html-entry 包来获取并处理子应用资源的。

qiankun首先通过URL获取到整个HTML文件，从HTML中解析出HTML，JS和CSS文本。在主应用中创建容器，把HTML更新到容器中。然后动态创建style和script标签，把子应用的css和js赋值在其中，最后把容器放置在主应用中。具体过程如下：

• a：qiankun 会用 原生fetch方法，请求微应用的 entry 获取微应用资源，然后通过 response.text 把获取内容转为字符串。

• b：将 HTML 字符串传入processTpl函数，进行 HTML 模板解析，通过正则匹配 HTML 中对应的 javaScript（内联、外联）、css（内联、外联）、代码注释、entry、ignore 收集并替换，去除 html/head/body 等标签，其他资源保持原样。

• c：将收集的 styles 外链URL对象通过 fetch 获取 css，并将 css 内容以 <style> 的方式替换到原来 link 标签的位置。

• d：收集 script 外链对象，对于异步执行的 JavaScript 资源会打上 async 标识 ，会使用 requestIdleCallback 方法延迟执行。

• e：接下来会创建一个匿名自执行函数包裹住获取到的 js 字符串，最后通过 eval 去创建一个执行上下文执行 js 代码，通过传入 proxy 改变 window 指向，完成 JavaScript 沙箱隔离。

• f：由于 qiankun 是自执行函数执行微应用的 JavaScript，因此在加载后的微应用中是看不到 JavaScript 资源引用的，只有一个资源被执行替换的标识。

• g：当一切准备就绪的时候，执行微应用的 JavaScript 代码，渲染出微应用。

（2）局限性

qiankun不是一个完整的微前端解决方案！！！

微前端的运行时容器

• a：qiankun 所帮你解决的这一块实际上是微前端的运行时容器，这是整个微前端工程化里面其中一个环节。

• b：从这个角度来讲 qiankun 不算是一个完整的微前端解决方案，而是微前端运行时容器的一个完整解决方案，当你用了 qiankun 之后，你几乎能解决所有的微前端运行时容器的问题，但是更多的一些涉及工程和平台的问题，则需要我们去思考与处理。

• c：我们的版本管控、配置下发、监控发布，安全检测、等等这些怎么做，都不是 qiankun 作为一个库所能解答的，这些问题得根据具体情况，来选择适合自己的解决方案。

• d：对于老旧项目的接入，很难做到零成本迁移，在开发的时候要预留足够的踩坑，魔改代码的时间。如果是已经维持几年堆叠的屎山需要做好因为不规范编码，所产生的各种奇怪的兼容性问题，这个时候你甚至会怀疑，“微前端是否真的有必要?”

• e：微前端的核心不是多技术共存，而是分解复杂度，提升协作效率，支持灵活扩展，能把“一堆复杂的事情”变成“简单的一件事情”，但是也不是无脑使用的，广东话来说“多个香炉多只鬼”，每多一个技术栈都会增加：维护成本，兼容成本，资源开销成本，这些都会无形的拖累生产力。

• f：基座应用与微应用之间，强烈推荐使用相同的技术栈，相同的技术栈可以实现公共依赖库、UI库等抽离，减少资源开销，提升加载速度，最重要的是：“减少冲突的最好方式就是统一”，通过约束技术栈可以尽可能的减少项目之间的冲突，减少工作量与维护成本。

标准化才能提升生产力

• a：混乱的项目会拖累生产效率，同时混乱的微前端也会加剧内耗，所以只有标准化才能提升生产力。

• b：解决微前端的接入问题是最简单的，但是微前端接入后的：工程化，应用监控，应用规范，应用管理才是微前端中困难的地方，如果你只是想简单的嵌入一个应用，我推荐你的使用 iframe

（3）微前端（qiankun）实战

关于qiankun的使用，以及使用过程中的各类问题请查看：微前端（qiankun）使用手册

4. MicorApp

MicroApp是京东基于类WebComponent进行渲染的微前端框架，不同于目前流行的开源框架，它从组件化的思维实现微前端，旨在降低上手难度、提升工作效率。它是目前市面上接入微前端成本最低的框架，并且提供了JS沙箱、样式隔离、元素隔离、预加载、资源地址补全、插件系统、数据通信等一系列完善的功能。

关于microApp实战请查看：微前端（micro-app）使用手册

5. 无界

无界微前端是腾讯基于 Web Components + iframe 开发的微前端框架，具备成本低、速度快、原生隔离、功能强等一系列优点。

6. Module Federation以及EMP

Module Federation是webpack5中的新特性，主要是用来解决多个应用之间代码共享的问题，可以更加优雅的实现跨应用的代码共享，使用这个方法也可以实现微前端。

这个方案中有两个主体：Remote和Host，可以把Remote理解为想要引入的子应用，把Host理解为主应用（但是一个应用既可以是Remote也可以是Host，并不矛盾）。

Module Federation的核心在于ModuleFederationPlugin这个插件：

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

/**
 * name: （必须）唯一ID，作为输出的模块名，使用的时通过name/{expose}的方式使用
 * library：（必须）其中这里的name为作为umd的name
 * remotes：（可选）表示作为Host时，去消费哪些Remote
 * exposes：（可选）表示作为Remote时，export哪些属性被消费
 * shared：（可选）优先用Host的依赖，如果Host没有，再用自己的
 */
new ModuleFederationPlugin({
  name: "App1",
  library: { type: "var", name: "App1" },
  filename: "remoteEntry.js",
  remotes: {
    app_02: 'App2',
    app_03: 'App3',
  },
  exposes: {
    antd: './src/antd',
    button: './src/button',
  },
  shared: ['react', 'react-dom'],
})

通过以上设置打包之后会生成三种文件：应用主文件：main.js、作为remote时被引用的文件remoteEntry.js和其他的异步加载文件。

这里通过一个例子简单概括一下其原理：下图是三个项目，在App1中它的remotes是App2和App3，没有exposes，shared是React和ReactDom，它作为host使用了remote的dialog组件和button组件；App2作为host使用了App3的button组件，作为remote导出来dialog组件，在App1中运行时如果需要使用React则会优先把App1中的React导入，这就复用了公共库；App3向外导出了dialog组件，只作为其他项目的remote。

这个新特性的提出促进了更多工具的发展，EMP就是以此为基础构建出的一个跨应用共享资源的框架，这个框架优化协作，加速开发的同时还可以保持UI的一致性。

7. 选型

（1）考虑系统需要兼容 ie 浏览器场景：wujie > qianku

（2）接入便捷度考虑：wujie > micro-app > qiankun

（3）框架稳定性 (框架成熟度)：qiankun > micro-app > wujie

微前端意义

1. 化整为零

当下前端领域，单页面应已经成为流行的的项目形态之一，但是随着时间和技术的发展，原本单一的应用具备的功能愈加丰富起来，功能的丰富意味着越来越难以维护，从而变成一个巨石项目。以至于之后改一处而动全身，带来的发版成本也更高。微前端的意义就是将巨石应用进行拆分，化整为零把功能随之解耦，每个部分可以单独进行维护和部署，从而提升团队开发和维护效率。

2. 化零为整

在业务中或多或少会存在一些历史项目，这些项目也会使用不同的框架进行构建，在日常运营中，这些系统已经有固有的用户，但是诸多的应用对于用户来说也是一种成本，为了让旧项目焕发新生，这要求我们在不能抛弃原有项目的同时开发新的功能，把诸多较为零散的入口统一整合起来，从而提高系统的使用率，而微前端就是目前实现这一需求的较好方法。

综上，微前端不一定是未来发展趋势的收束点，但是它在未来一定会发挥重要作用。

你真的需要微前端吗？

1. 微前端是「康威定律」在前端架构上的映射

设计系统的架构受制于产生这些设计的组织的沟通结构。 — M.Conway

康威定律几乎就是微前端（准确来说是微服务架构）的理论基础了。它指出了组织架构越庞大，其系统间沟通成本越高的问题。而解决这一问题的有效手段就是，将大的系统拆分成一个个微小的，可以独立自治的子系统。一旦系统的依赖限制在了内部，功能上更加内聚，对外部的依赖变少，那么就能显著的减少跨系统之间的沟通成本了。

简单来说，康威定律的指导思想就是：既然沟通是大问题，那么就不要沟通就好了。

所以本质上，微前端(微服务架构)关注的是如何解决组织和团队间协作带来的工程问题，而不是单纯的某个技术问题。

qiankun的作者当初面对的问题是有一些系统都是 4年+、代码 20W行+ 的长尾应用，而产品还在持续的集成迭代，既没精力去给他们做技术栈升级，也没动力(兴趣)去跟一个个前应用 owner 沟通了解一些技术细节。这可间接的引出第二个观点。

2. 微前端的假设是，所有大型系统都逃不过熵增定律

这个假设指的是，所有大型系统都将从有序变为无序，他们背后的 codebase 的归宿都将是「屎山」。

如果不是，那一定是因为这个系统使用的技术栈更新的不够快，参与系统开发的工程师不够多，产品迭代的时间不够长。

在潜意识里，微前端的采纳者就不相信一个系统会永远健康的迭代下去。因为熵增永远是自然且轻松的，而对抗熵增，则必须有足够的外力介入、足够的成本投入才行。

这也是为什么，qiankun 的很大一批用户，都是因为要在一批长尾应用上迭代新功能，最后实在搞不动，才会尝试用微前端的方案来解决了。

基于此，微前端很多时候是「悲观主义工程师」在工程上的妥协，是一种防御性，有时候甚至是「掩耳盗铃」式的架构策略。

当然在理想状态下，对于一个有追求的工程师而言，所有的技术问题都应该是被正面修复、正确治理的，而不是起手就来一个 workaround。但同时所有的软件工程原则也都会告诉我们，不遗余力、不计成本的去优化、解决一个技术问题是不可取的，尤其是在这个问题的投入产出比不高的情况下。

微前端倡导的不是消极的、投降主义的去回避系统中的历史遗留问题，而是告诉我们，很多时候我们可以通过分而治之的手段，让「上帝的归上帝，凯撒的归凯撒」。

3. 满足以下几点，你可能就不需要微前端

基于以上两个观点，我们可以概括出，存在以下场景时，你可能就不需要微前端：

（1）你/你的团队 具备系统内所有架构组件的话语权

（2）简单来说就是，系统里的所有组件都是由一个小的团队开发的。你/你的团队 有足够动力去治理、改造这个系统中的所有组件

（3）直接改造存量系统的收益大于新老系统混杂带来的问题。系统及组织架构上，各部件之间本身就是强耦合、自洽、不可分离的

（4）系统本身就是一个最小单元的「架构量子」，拆分的成本高于治理的成本。极高的产品体验要求，对任何产品交互上的不一致零容忍。不允许交互上不一致的情况出现，这基本上从产品上否决了渐进式升级的技术策略

4. 满足以下几点，你才确实可能需要微前端

（1）系统本身是需要集成和被集成的 一般有两种情况：

• a. 旧的系统不能下，新的需求还在来。

• b. 没有一家商业公司会同意工程师以单纯的技术升级的理由，直接下线一个有着一定用户的存量系统的。而你大概又不能简单通过 iframe 这种「靠谱的」手段完成新功能的接入，因为产品说需要「弹个框弹到中间」你的系统需要有一套支持动态插拔的机制。

（2）这个机制可以是一套精心设计的插件体系，但一旦出现接入应用或被接入应用年代够久远、改造成本过高的场景，可能后面还是会过渡到各种微前端的玩法。系统中的部件具备足够清晰的服务边界

通过微前端手段划分服务边界，将复杂度隔离在不同的系统单元中，从而避免因熵增速度不一致带来的代码腐化的传染，以及研发节奏差异带来的工程协同上的问题。还是那个老生常谈的理念，没有银弹，架构本身就是各种 trade–off。

大部分时候，一个「流行」的东西，你都无法阻止不需要它的人去使用它。

如果在项目采用vite构建的前提下需要使用qiankun，请查看文档《微前端qiankun接入Vite构建的子应用》。

如果主应用路由模式需要使用hash，请查看文档《微前端（qiankun）Hash路由实践》。

创建主应用

1.安装qiankun

1

`yarn add qiankun` 或者 `npm i qiankun -S`

2. 注册微应用

在入口文件main.js中注册所有微应用并启动qiankun。

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

import { registerMicroApps, start, addGlobalUncaughtErrorHandler, initGlobalState } from 'qiankun'

// 1. 定义所有微应用
const apps = [
  {
    // 必须与子应用注册名字相同
    name: 'micro-app-vue2',
    // 入口路径，开发时为子应用所启本地服务，上线时为子应用线上路径
    entry: '//localhost:3003',
    // 子应用挂载的节点
    container: '#micro-app-vue2',
    // 当访问路由为 /micro-app-vue2 时加载子应用
    activeRule: '/micro-app-vue2',
    // 主应用向子应用传递参数
    props: {
        msg: "我是来自主应用的值"
    }
  },
  {
    name: 'micro-app-vue3',
    entry: '//localhost:3001',
    container: '#micro-app-vue3',
    activeRule: '/micro-app-vue3'
  },
  {
    name: 'micro-app-react',
    entry: '//localhost:4001',
    container: '#micro-app-react',
    activeRule: '/micro-app-react'
  }
]

// 2. 微应用生命周期
// qiankun暴露了五个生命周期钩子：beforeLoad、beforeMount、afterMount 、beforeUnmount和afterUnmount，这五个钩子可以在主应用中注册子应用时使用。
const microAppLifCycles = {
  beforeLoad: [ // 全局的微应用生命周期钩子，子应用加载前
    app => {
      console.log('子应用加载-beforeLoad', app)
      return Promise.resolve()
    }
  ],
  beforeMount: [ // 全局的微应用生命周期钩子，子应用挂载前
    app => {
      console.log('2-beforeMount', app)
      return Promise.resolve()
    }
  ],
  afterMount: [ // 全局的微应用生命周期钩子，子应用挂载后
    app => {
      console.log('3-afterMount', app)
      return Promise.resolve()
    }
  ],
  beforeUnmount: [
    app => {
      console.log('4-beforeUnmount', app)
    }
  ]
}

// 3. 注册微应用的基础配置信息（第二个参数可选）
registerMicroApps(apps, microAppLifCycles)

// 4. 添加全局的未捕获异常处理器
addGlobalUncaughtErrorHandler((event) => {
  const { message: msg } = event
  if (msg && msg.includes('died in status LOADING_SOURCE_CODE')) {
    console.error('微应用加载失败，请检查应用是否可运行', event)
  }
})

// 5. 启动微应用
start({
  prefetch: true, // 是否开启预加载
  sandbox: {
    experimentalStyleIsolation: true // 实验性的样式隔离
  }
})

关于预加载微应用prefetch的属性说明：

（1）配置为 true 则会在第一个微应用 mount 完成后开始预加载其他微应用的静态资源

（2）配置为 all 则主应用 start 后即开始预加载所有微应用静态资源

（3）配置为 string[] 则会在第一个微应用 mounted 后开始加载数组内的微应用资源

（4）配置为 function 则可完全自定义应用的资源加载时机 (首屏应用及次屏应用)

当微应用信息注册完之后，一旦浏览器的 url 发生变化，便会自动触发 qiankun 的匹配逻辑，所有 activeRule 规则匹配上的微应用就会被挂载到指定的 container 中，同时依次调用微应用暴露出的生命周期钩子。

3.创建微应用SFC

每个微应用使用一个对应的单文件组件进行挂载，并在mounted中进行判断如果未开启qiankun则进行开启。

该处以microAppVue2组件为例，其它组件只需要修改id和组件name。

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

<template>
   <!-- 这个id需要和注册微应用中的container的值对应 -->
  <div id="micro-app-vue2"></div>
</template>

<script>
import { start } from 'qiankun'
export default {
  name: 'microAppVue2',
  components: {},
  mounted () {
    if (!window.qiankunStarted) {
      window.qiankunStarted = true
      start({
        prefetch: true, // 是否开启预加载
        sandbox: {
          experimentalStyleIsolation: true // 实验性的样式隔离
        }
      })
    }
  }
}
</script>

4.路由配置

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

import Vue from 'vue'
import VueRouter from 'vue-router'
Vue.use(VueRouter)

const routes = [
  {
    // 这个path需要和注册微应用中的activeRule的值对应
    path: '/micro-app-vue2',
    component: () => import('@/views/microAppVue2/index.vue')
  },
  {
    path: '/micro-app-vue3',
    component: () => import('@/views/microAppVue3/index.vue')
  },
  {
    path: '/micro-app-react',
    component: () => import('@/views/microAppReact/index.vue')
  }
]

const router = new VueRouter({
  // 选择history模式时，需要设置base，这样在访问路由时会自动带上项目的基路径
  mode: 'history',
  base: process.env.BASE_URL,
  routes
})

export default router

5.主应用代理微应用的接口地址

在使用 qiankun 微前端框架时，主应用可以通过配置代理来转发子应用的接口请求。这样可以解决跨域问题和统一管理接口访问。

首先，在主应用的配置文件中（例如 webpack.config.js）添加以下代码：

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

const { createProxyMiddleware } = require('http-proxy-middleware');

module.exports = {
  // ...其他配置

  devServer: {
    // ...其他 devServer 配置项

    // 添加代理配置
    proxy: {
      '/api': {
        target: 'http://子应用的接口地址',
        changeOrigin: true,
        pathRewrite: {
          '^/api': '', // 如果子应用接口有基础路径，需要进行重写
        },
      },
    },
  },
};

上述代码中，将 /api 路径下的请求转发到了子应用的接口地址，并进行了域名跨域处理。你可以根据实际情况修改目标地址和路径重写规则。

然后，在微应用中调用接口时，使用相对于主应用的 /api 路径作为前缀，例如：

1
2
3
4

fetch('/api/users')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error(error));

这样就能将请求发送给子应用的接口地址，并成功获取响应数据。

注意：以上示例是基于 webpack-dev-server 进行配置的，在生产环境部署时需要根据实际情况配置代理服务器。

创建微应用

vue2、vue3和react的配置由于框架不同而在代码上有些微区别（比如vue2创建实例是new vue，vue3是createApp），但整体qiankun的配置步骤和配置内容相同。此处不做区分，以下仅以vue2为例：

1.修改配置文件

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

// vue.config.js

// 1. package.json中name的值必须和主应用中注册微应用的name的值对应
const packageName = require('./package.json').name;
module.exports = {
    configureWebpack: {
        // 2. 打包方式改造
        output: {
            library: packageName,
            // 这里设置为umd意思是在 AMD 或 CommonJS 的 require 之后可访问。
            libraryTarget: "umd",
            // webpack用来异步加载chunk的JSONP 函数。
            jsonpFunction: `webpackJsonp_${packageName}`,
        },
    },
    devServer: {
        port: "3003",
        disableHostCheck: true, // 关闭主机检查，使微应用可以被 fetch
        headers: {
            // 3. 因为qiankun内部请求都是fetch来请求资源，所以子应用必须允许跨域    "Access-Control-Allow-Origin": "*",
        },
    }
};

为什么 qiankun 要求子应用打包为 umd 库格式呢？

主要是为了主应用能够拿到子应用在 入口文件 导出的 生命钩子函数，这也是主应用和子应用之间通信的关键。

umd全称是UniversalModuleDefinition，是一种通用模块定义格式，通常用在前端模块化开发中。

由于不同的模块化规范定义不同，为了让各种规范的模块可以通用，在不同的环境下都可以正常运行，就出现了umd这个通用格式。

umd 格式是一种既可以在浏览器环境下使用，也可以在 node 环境下使用的格式。它将 CommonJS、AMD以及普通的全局定义模块三种模块模式进行了整合。

2.修改publicPath

src目录下新建public-path.js，用于处理打包后静态资源的路径问题。内容如下：

1
2
3
4

if(window.__POWERED_BY_QIANKUN__) {
  // eslint-disable-next-line no-undef
  __webpack_public_path__ = window.__INJECTED_PUBLIC_PATH_BY_QIANKUN__;
}

3.路由配置

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

import Vue from 'vue'
import Router from 'vue-router'
import HelloWorld from '@/components/HelloWorld'
 
Vue.use(Router)
 
export default new Router({
  // 1. 设置history模式
  mode: 'history',
  // 2. 设置base，值和主应用中的activeRule保持一致
  base: window.__POWERED_BY_QIANKUN__ ? "/micro-app-vue2" : "/",
  routes
})

当使用vue-router v4.x时，是通过createRouter的方式实例化router，设置histroy和base通过如下方式：

1
2
3
4
5

// 1. Hash路由设置方法，hash不需要设置base
history: createWebHashHistory(), 

// 2. 设置 History 路由时必须添加base
// history: createWebHistory(qiankunWindow.__POWERED_BY_QIANKUN__ ? '/micro-app-vue3-vite' : '/'),

当微应用为History时，主应用的router/index.js中必须多添加一项路由配置：

1
2
3
4
5
6
7
8
9

// ...
{
    hidden: true,
    name: 'microAppVue2',
    // 匹配微应用的路由
    path: '/micro-app-vue2/*',
    component: () => import('@/views/microAppVue2/index.vue')
},
// ...

4.入口文件修改

修改入口文件main.js，修改内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

// 1. 顶部引入public-path
import './public-path'
import Vue from 'vue'
import App from './App'
import router from './router'

Vue.config.productionTip = false

// 2. 定义一个Vue实例
let instance = null

// 3. 渲染方法
function render(props = {}) {
  const { container } = props
  instance = new Vue({
    router,
    render: (h) => h(App)
  }).$mount(container ? container.querySelector('#app') : '#app')
}

// 4. 判断是否在qiankun环境下，非qiankun环境下独立运行
if (!window.__POWERED_BY_QIANKUN__) {
  render()
}

// 5. 暴露qiankun生命周期钩子
export async function bootstrap() {}
export async function mount(props) {
  render(props);
}
export async function unmount() {
  instance.$destroy();
  instance.$el.innerHTML = '';
  instance = null;
}

项目在迁移成子应用时，需要在入口文件配合qiankun来做一些改动，而这些改动有可能影响子应用的独立运行。为了解决子应用也能独立运行的问题，qiankun注入了一个变量：window.__POWERED_BY_QIANKUN__，这样就可以判断当前应用是否在独立运行。

但是变量需要在运行时动态的注入，那么该变量设置的位置就需要考虑清楚，qiankun选择在single-spa提供的生命周期前进行变量的注入，在beforeLoad和beforeMount中把变量置为true，在beforeUnmount中把变量置为false。

和single-spa一样，qiankun子应用的接入必须暴露三个生命周期：

（1）Bootstrap：只会在微应用初始化的时候调用一次，下次微应用重新进入时会直接调用 mount 钩子，不会再重复触发 bootstrap。通常我们可以在这里做一些全局变量的初始化，比如不会在 unmount 阶段被销毁的应用级别的缓存等。

（2）Mount：应用每次进入都会调用 mount 方法，通常我们在这里触发应用的渲染方法。

（3）Unmount：应用每次 切出/卸载 会调用的方法，通常在这里我们会卸载微应用的应用实例。

主应用和微应用通信

1.主应用中注册全局状态

在入口文件main.js中定义并监听全局状态

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

import { initGlobalState } from 'qiankun'

// 定义全局状态，并返回通信方法，建议在主应用使用，微应用通过 props 获取通信方法
const { onGlobalStateChange, setGlobalState } = initGlobalState({
  user: 'qiankun'
})

// 在当前应用监听全局状态，有变更触发 callback
onGlobalStateChange((value, prev) => console.log('[onGlobalStateChange - main]:', value + prev))

// 按一级属性设置全局状态,微应用中只能修改已存在的一级属性
setGlobalState({
  ignore: 'master',
  user: {
    name: 'master'
  }
})