说到“野球拳”，你最先想到的是哪一款游戏呢？

还记得在街机游戏盛行的年代，能破解的热门游戏数量非常有限，因此盗版商们动起了其他主机平台的心思。MD和SFC则是被盗版移植最多的平台，大量经典的游戏出现在游戏厅，并使用摇杆和按键操作，毫无违和感。然而却很少有人知道，SS的一些经典游戏也曾经出现在游戏厅时期，其中最经典的自然就是玩家们耳熟能详的《野球拳》。

这款游戏的存在，在当时来说绝对是一个异类。甚至不知道该怎么分类呢？益智？动作？休闲？误导？教学？似乎都有吧！剪刀石头布的游戏，看似简单，但真的玩下来就是心理战术了。

那时候，哪一家游戏厅有这么一台游戏，绝对会引爆全场，甚至周边的玩家都会集结过来围观，造成其他的游戏厅冷清了不少。可想而知，那时候玩家求知心理有多强烈，以及《野球拳》的人气之高有多高。

其实在那个年代，类似《野球拳》的游戏不在少数。只是大部分因为尺度的原因，都只能在主机平台才能玩到，在国内基本上没有正版的发行。那时候的玩家能够接触到纯属侥幸。当然，游戏厅也有其他游戏可以替代，类似《天蚕变》《麻雀》《柏青哥》之类的益智游戏，不过启蒙的力度并没有那么强烈。

《碧蓝之海》最火爆的野球拳场面，看过真人版的宣传之后各位还好吗？

野球拳，最初是为棒球选手呐喊助威的歌曲，从二三十年代一直保留至今。在经过很长一段时间之后，在七十年代的日本综艺节目带动下，渐渐演变成脱衣猜拳的代名词。甚至最终渐渐演变成为某种高级武功和技能，当然其中的恶趣味只有年长一点的人才知道。在进入这些游戏之后，野球拳拥有了类似“王八拳”“流氓拳”之类的含义。

《金庸群侠传》野球拳一战成名

游戏中可以学习的技能非常之多，基本上每个人身上都可以获得秘籍。而那些书中出现过的秘籍，在客栈里面的韦小宝那里都可以购买。甚至连金轮法王的龙象般若功都可以买到。在小说中比较厉害的武功，类似《葵花宝典》《六脉神剑》《降龙十八掌》《黯然销魂掌》《辟邪剑法》......打出来的伤害都是比较高的。

要是在老顽童哪里学到了左右互搏，基本上就天下无敌了。但是学这一招的前提条件是：智商偏低，很符合原著嘛！

《辟邪剑法》在学习之前还会询问：自宫与否。别说，当时为了成为高手，还真有不少玩家选择自宫了。也是在很久之后，在同学那里才知道原来“野球拳”才是最厉害的。不过如果排除“野球拳”的话，《辟邪剑法》《葵花宝典》当真可以独步武林，威力甚至大于降龙十八掌。

自宫也值得，反正自己不练，让那些恶棍加入，逼他们学习，然后再遣散。

“野球拳”在金庸小说中并未出现过，《金庸群侠传》是主人公从现实中带到游戏中的技能。在游戏中的含义类似“乱拳打死老师傅”。其实最初玩家们并不知道这一招的威力如何，其他武功升一级就会提升一级的威力，但是野球拳学到第九级也没有什么威力，不少人因此放弃了。

金花婆婆是我们练拳最佳伴侣，反正打不死，可以无限挑战。野球拳挥动近70下才能升一级，想要获得十层功力，得打将近一千次啊！只要学会十级野球拳，除了辅助技能，其他功夫基本上都不需要学习了。

即使是游戏中的顶级战力张三丰，也无法抵挡野球拳的威力。

第一次见面，张三丰：“小伙子，过来让我指点你一下！”

“你已经这么吊了，我没什么好教给你的，个人爬！”然后三本顶级武功秘籍也别想得到手。

不过说实话，游戏早期练成了野球拳+左右互搏的话，就变得一点挑战性都没有了，再强的敌人，类似金轮法王、欧阳锋、东方不败都是一套拳直接带走。跟班也完全是跟着混经验而已。其他的什么武功秘籍，在野球拳面前都没有什么价值。

反而是最初玩的时候，什么武功都学，什么人都招纳，最后勉强打败敌人获取经验的时候最开心。

《武林群侠传》野球拳延续经典

在《金庸群侠传》精神续作《武林群侠传》中，野球拳再次被启用，剧情中说是昔日英雄小虾米的成名绝技，其实就是《金庸群侠传》中的主角。而在路边玩杂耍的齐丽，则是野球拳的传人。

在这款游戏中，野球拳的作用改变了，是“探测敌意，先发制人”的“招意”，野球拳再次被封神。

想要学会这一招的话，就需要引发剧情了。首先在集市上认识齐丽，并帮她打退黑风寨的人。第二年4月上旬到第三年12月底期间去森林跟她猜拳，第三年会在森林中遇到齐丽的父亲，此时如果玩家的医术达到七十以上，加上采集药材：羚羊角、鳖甲、麝香，就可以成功救治。好感度增加之后就能学会这一招了。游戏中的神技啊！

在《侠客风云传》中剧情也是差不多的，想学会野球拳就必须和齐丽搞好关系。

这里帮齐丽老爹疗伤的技能是“一阳指”，“一阳指”在养成模式帮助李徽私奔就可以获得，帮她爹疗伤的成功之后，第四年七夕齐丽会亲自来送你野球拳秘籍。

在《侠客风云传》中野球拳仍然是伤害最高的武功。

小编的图文主要专注于街机游戏和红白机，希望可以唤起这代人的美好回忆。

喜欢怀旧游戏的朋友别忘记关注哦！每天可以第一时间查看内容更新。

文章都是经过长时间整理和创作，纯手工打字，绝无水贴。

街机123游戏厅手机版软件是一款非常有趣的经典街机模拟器，在街机123游戏厅软件里面给大家设计了大量丰富的经典街机游戏，都可以让小伙伴们免费的去畅玩，找回儿时的回忆，非常有趣，有兴趣的下面一起来下载试试吧!谢谢。

街机123游戏厅app介绍

街机123游戏厅app是一款街机游戏平台，内置了最新版本的MAME仿真器和数百种经典的街机游戏，可让您回忆小时候玩游戏的感觉，让您回忆在街机大厅的感觉当你还是个孩子!

街机123游戏厅app亮点

成千上万的作者努力创造，大量协助您选择

作为开放的辅助作者开放平台，上面有许多精英作者。每个玩家每天都能从作者那里找到自己需要的帮助，这是意外的，没有帮助就不可能。

超级兼容，可适应任何一种操作环境

它与市场上超过98%的android模拟器完全兼容。无论您使用的是田田，夜神，伊特尔，海达，新浪移动游戏助手还是可靠的助手，只要您的计算机上有任何Android模拟器，都可以享受密切的帮助。

体积小，占用资源少，操作简单，即用型

秉承轻巧设计的理念，从播放器的角度来看一切，人性化的软件设计可以帮助播放器节省每一次宝贵的时间，计算机配置不足吗?通过!轻量级不占用单个多余资源;电脑痛吗?通过!简单的操作使您轻松使用辅助衣架。没有固定装置?通过!

街机123游戏厅app详情介绍

玩最经典的视频游戏。内置浏览页面，网络搜索ROM快速便捷。

精美的用户界面，模拟器操作简单易用。完美解决虚拟按钮多点触控问题，还原真正的街机操纵杆操作乐趣。

拳皇，街头霸王，超级玛丽，魂斗罗，三个王国...通用多功能模拟器，

在街机模拟器中免费获得广告免费，数量不限的硬币。专注于模拟器优化，更多高质量平台集成，敬请期待!

街机123游戏厅app特色

提供免费的游戏ROM，无需安装即可立即播放;

高速下载易于管理，海量资源绿色安全;

集成的多模拟器平台，可以掌握经典游戏;

解决多点触控问题并享受最佳的触控体验。

前端工程师，我们编写的代码只能活在浏览器、小程序或者 Node 进程里，这似乎已经成为了一种常识。但这就是我们的能力边界了吗？本文将带你为一台内存仅 32M，分辨率仅 320x240 的掌上游戏机适配前端工具链，见证 Web 技术栈的全新可能性。

本次我们的目标，是只配备了 400Mhz 单核 CPU 和 32M 内存的国产怀旧掌机 Miyoo。它固然完全无法与现在的 iOS 和安卓手机相提并论，但却能很好地在小巧精致的体积下，满足玩小霸王、GBA、街机等经典游戏平台模拟器的需求，价格也极为低廉。这是它和 iPad mini 的对比图：

那么，怎样才算是为它移植了一套前端技术栈呢？我个人的理解里，这至少包括这么几部分：

• 构建环境 - 应用编译工具链

下面将逐一介绍为完成这三大部分的移植，我所做的一些技术探索。这主要包括：

入门嵌入式开发时我们首先应该做到的，就是将源码编译为嵌入式操作系统上的应用。那么 Miyoo 掌机的操作系统是什么呢？这里首先有一段故事。

Miyoo 是个国内小公司基于全志 F1C500S 芯片方案定制的掌机，其默认的操作系统是闭源的 Melis OS，在国外以 Bittboy 和 Pocket Go 的名义销售，小有名气。闭源系统自然不能满足爱好者的需求，因此社区对其进行了逆向工程。来自台湾的前辈司徒 (Steward Fu) 成功将 Linux 移植到了这台掌机上，但可惜他已因个人原因退出了开发。现在这台游戏机的开源系统 MiyooCFW 基于司徒最早移植的 Linux 4.14 内核，由社区维护。

因此，我们的目标系统既不是 iOS 也不是安卓，而是原汁原味的 Linux！如何为嵌入式 Linux 编译应用呢？我们需要一套由编译器、汇编器、链接器等基础工具组成的工具链，以构建出可用的 ARM 二进制程序。

在各个操作系统上搭建开发环境，往往相当繁琐。现在开源掌机社区中流行的方式是使用 VirtualBox 等 Linux 虚拟机。这基本解决了工具链的跨平台问题，但还没有达到现代前端工程的开发便利度。因此我选择首先引入 Docker，来实现跨平台开箱即用的开发环境。

我们知道，Docker 容器可以理解为更轻量的虚拟机。我们只要一句 docker run 命令就能运行容器，并为其挂载文件、网络等外部资源。显然，现在我们需要的是一个【能编译出嵌入式 Linux 应用】的 Docker 容器，这可以通过制作出一个用于启动容器的基准 Docker 镜像来实现。Docker 镜像很容易跨平台分发，因此只要制作并上传镜像，基础的开发环境就做好了。

那么，这个 Docker 镜像中应该包含什么内容呢？显然就是编译嵌入式应用的工具链了。司徒已为社区提供了一套在 Debian 9 上预编译好的工具链包，只需要将其解压到 /opt/miyoo 目录下，再安装一些常见依赖，就可以完成镜像的制作了。这一过程可以通过 Dockerfile 文件来自动化，其内容如下所示：

这样只要用 docker build 命令，我们就能用纯净的 Debian 镜像制作出纯净的嵌入式开发镜像了。那么接下来又该如何用镜像编译文件呢？假设我们做好了 miyoo_sdk 镜像，那么只要将本地的文件系统目录，挂载到基于镜像所启动的容器上即可。像这样：

简单说来，这条命令的意义是这样的：

• -it 让我们用当前终端来登录操作容器的 Shell

• --rm 使容器用完即弃，除更改当前目录外，不留任何痕迹

因此，我们实际上基于 Docker，直接在容器里编译了 Mac 文件系统上的源码。这既没有副作用，也不需要其他数据传递操作。对于日益复杂的前端工具链依赖问题，我相信这也是一种解决方案，有机会可以单独撰文详述。

Docker 镜像制作好之后，我们就能用上容器里 arm-linux-gcc 这样的编译器了。那么该怎么编译出一个 Hello World 呢？现在还没到引入 JS 引擎的时候，先用 C 语言写出个简单的例子，验证一切都能正常工作吧。

嵌入式 Linux 设备常用 SDL 库来渲染基础的 GUI，其最简单的示例如下所示，是不是和前端同学们熟悉的 Canvas 有些神似呢：

这份 C 源码可以通过我们的 Docker 环境编译出来。但显然稍有规模的应用都不应该直接敲 gcc 那堆参数来直接构建，通过像这样的 Makefile 来自动化比较好（注意缩进必须用 tab 哦）：

除了登陆 Docker 容器的 Shell 之外，我们还可以通过 -d 参数轻松地创建「无头」的容器，在后台帮你编译。像构建这个 Makefile 所需的 make 命令，就可以在 Mac 终端里这样一行搞定：

这说明 Docker 编译工具链已经正常工作了！但这还远远不够，现在的关键问题在于，我们的 printf 去哪了？

基础的 Unix 知识告诉我们，进程的输出是默认写到 stdout 这个标准输出文件里的。一般来说，这些输出都会写入流式的缓冲区，进而绘制到终端上。但是，嵌入式设备的终端在哪里呢？一般来说，这些日志写入的是所谓的 Serial Console 串口控制台。而这种控制台的数据，则可以通过非常古老的 UART 传输器来和 PC 交互，只需要接上三条电路的连线就行。

因此，我们需要想办法接通 Miyoo 的 UART 接口，从而才能在电脑上登陆它的 Shell。在这方面，司徒的 焊接 UART 接頭 这篇文章是非常好的参考资料。我对其中的一句话印象尤其深刻：

廠商真是貼心，特別把 GND、UART1 RX、UART1 TX（由上而下）拉出來，提供開發者一個友好的開發界面

拆机焊接才能用的东西，在大佬眼里居然算是友好的开发界面…好吧，不就是焊接吗？现学就是了。

首先我们把后盖拆开，再把主板卸下来。这步只需要标准的十字螺丝刀，注意别弄丢小零件就行。完成后像这样：

看到图中主板右上角的三根针了吗？这就是 UART 的三个接口了（这时我还没焊接，只是把排针摆上去了而已）。它们自上而下分别是 GND、RX 和 TX，只要为它们焊接好排针，将导线连到 UART 转 USB 转换器，就能在 Mac 上登陆它啦。连接顺序是这样的：

所以，我们需要先焊上排针。焊接看起来很折腾，现学起来倒并不难，其实只要先把烙铁头压在焊点上，然后把焊锡丝放上去就行。像我这样的新手，还可以买一些白菜价的练习板，拿几个二极管练练手后再焊真的板子。完成后的效果如下所示，多了三根红色排针（焊点在背面，很丑就不放图了）：

焊好以后，用万用表即可测量焊点是否接通。还记得高中物理里万用表的红黑表笔怎么连接吗…反正我早就忘光了，也是现学的。实际测得 RX 和 TX 各自到 GND 的电阻值都在 600 欧姆左右，就代表连接畅通了。

加上转接头，连好之后的效果是这样的：

最后我为了能把机器装回去，又在后盖上打了个洞，像这样：

做完这个硬件改造之后，该如何实现软件上的连接呢？这就需要能够登陆串口的软件了。Unix 里一切皆文件，因此我们只要找到 /dev 目录下的串口文件，然后用串口通信软件打开这个文件就行啦。screen 是 Mac 内置的命令行会话软件，但用起来较为麻烦，这里推荐 Mac 用户使用更方便的 minicom。连接好之后，能看到形如这样的登陆日志输出：

看起来已经接近成功，可以 login 进去看日志了吧？结果一个 bug 拦住了我：所有按键按下去都没反应，完全登陆不了终端，怎么办？

我从来没做过这种层面的硬件改造，也没用过 UART 串口。因此这个问题对我相当棘手——既可能是硬件问题，也可能是软件问题。但总该是个可以解决的问题吧。

• 首先软件上，我反复确认了串口通信软件的配置，并梳理了 Linux 启动时的相关配置流程，将机器 EXT4 格式的 rootfs 分区挂载到 Mac 上，确认了 /etc/inittab 的配置和它启动的 /etc/main 脚本都是有效的，排除了设备侧的软件问题。

• 然后在硬件上，我确认了电路不存在虚焊，并实验改用树莓派与 Mac 做串口通信，确认了此时终端可以正常使用，排除了外围硬件的问题。

• 最后，我发现与树莓派通信时，Mac 侧按键可以让转接头的 RX 和 TX 灯都闪亮。但连接 Miyoo 时，按键时只会让 Mac 侧的 TX 发送端闪亮，没有收到本应经过 RX 返回的信号。因此推测问题在于这个接口的 RX 线路 。我整理了详尽的现象询问司徒后，得到的回复是：UART 与耳机共用，必须重新编译 Linux 内核才行。

好吧，我居然一路 debug 碰到了个物理电路设计的硬件问题。那就接着改 Linux 内核呗。

根据司徒提供的线索，我开始尝试将音频驱动从 Miyoo 的 Linux 内核源码中屏蔽掉。我们都知道 Linux 是宏内核，大量硬件驱动的源码全都在里面。简单改改驱动，其实不是件多高大上的事情。

首先，我们至少要能把内核编译出来。注意内核不等于嵌入式 Linux 的系统。一个完整的嵌入式 Linux 系统，应该大致包括这几部分：

• Kernel - 包含操作系统的核心子系统，以及所需的硬件驱动

• Rootfs - 根文件系统，大致就是根目录下面放的那堆二进制应用

• UBoot - 引导加载程序，本身相当于一个非常简单的操作系统

我们只是想禁用掉音频驱动，因此只需要重新编译出 Kernel 就行。Kernel 会编译成名为 zImage 的镜像。这个过程的用户体验其实和编译普通的 C 项目没有什么区别，也就是先配好编译参数和环境变量，然后 make 就行了：

在我 MacBook Pro 的 Docker 里，大致需要 12 分钟才能把内核编译出来。这里贴个图，纪念下职业生涯第一次编译出的 Linux 内核：

编译通过后，我非常开心地直接开始尝试修改内核的驱动（注意我没有真机测试这个第一次编译出的内核，这是伏笔）。经过一番研究，我发现嵌入式 Linux 的硬件都是通过一种名叫设备树的 DSL 代码来描述的，修改这种 DSL 应该就能使 Kernel 不支持某种硬件了。于是我找到了 Miyoo 设备树里的音频部分，将其注释掉，尝试编译出不包括音频的设备树描述文件，把它装上去。

然后机器启动后就黑屏了。

看来设备树的配置不管用，我又想到了直接修改音频驱动的 C 源码。它就是内核项目的 /sound/soc/suniv/miyoo.c，里面的 C 代码看起来并不难，但我尝试了不下七八种修改手法，就是编译不出一份正常的镜像：有时候可以解决 UART 无法登陆的问题，有时则不行，并且黑屏问题也始终没有解决。为什么音频驱动会影响视频输出，这让我十分困扰，甚至一度怀疑起了我的工具链。

最终，我得到了一个令人震惊的结论：

这份内核代码哪怕完全不改，编译出来都是会黑屏的。

于是，我换了社区版本的内核代码，屏幕顺利点亮，问题解决。

但是，社区版本的内核是老外维护的，他们的用户习惯里，A 键和 B 键的定义是相反的（小时候玩过美版 PSP 的同学应该知道我是什么意思）。于是我又开始折腾，尝试如何交换 A 和 B 的位置。

结果，我遇到了一个更加诡异的问题，那就是只要我在键盘驱动里交换 A 和 B 的值，要么不生效，要么就总会有其它的按键失灵，不能完全交换成功。

于是，我去仔细研究了按键驱动所对应的 Linux 内核 GPIO 部分的文档，检查了 init 和 scan 阶段下这一驱动的行为，甚至怀疑按键的宏定义会影响位运算的结果……结果都没什么卵用。但我还是找到了个能显示按键信息的调试用宏，之前一直懒得浪费一次编译时间去打开它，干脆把它启用后再试一下。

结果，我又得到了一个令人震惊的结论：

这份代码把变量的名字写错了。该对换的变量不是 A 和 B，是 A 和 X。

看来我果然没有写 Linux 内核的天赋，还是老老实实回去移植 JS 引擎吧。

搞定内核层以后，我们就可以轻松登录进 Miyoo 的控制台了。用户名是 root，没有密码。绕了这么多弯子，第一次登陆成功的时候还是让人很激动的。截图纪念一下：

接下来应用层的 JS 引擎移植，对我来说就是轻车熟路了。这里祭出我们的老朋友 QuickJS 引擎，它作为一个超迷你的嵌入式 JS 引擎，甚至已经兼容了不少 ES2020 里的特性。由于它没有任何第三方依赖，把它迁移到 Miyoo 上，其实并没有多难，给 Makefile

交叉编译自然也很难一帆风顺。这里我遇到的编译错误，都来自嵌入式环境下的标准库能力缺失。不过其实也只有这两点：

• malloc_usable_size  不支持，这会影响内存度量数据的获取，但 JS 照样可以跑得很欢。顺便一提从源码来看，这个能力在 WASM 里也不支持。所以其实已经有人把 QuickJS 编译成 WASM，玩起 JS in JS 的套娃了。

这点小问题，简单 patch 一下相关代码以后就搞定了。编译成功后，把它复制到 rootfs 分区的 /usr/bin 目录下，即可在在 Miyoo 的 Shell 里用 qjs 命令运行 JS 了。这下终于爽了，看我回到主场，噼里啪啦写段 JS 测试一下：

截图为证，我真的是在 Miyoo 里面跑的：

但是这个 JS 代码的运行结果又该怎么输出到真机上呢？我们知道 Linux

JS 都能跑了，日志都能看了，还要啥自行车呢？当然是支持给它下断点啊！我本来一直以为断点调试必须要用 V8 那样的重型引擎配合 Chrome 才行，结果让我惊喜的是，社区已经为 QuickJS 实现了一个支持调试器的 fork，这样只需要 VSCode 作为调试器前端，就能调试 QuickJS 引擎运行时的代码了。配合 VSCode 的 Remote 功能，这玩意的想象空间实在很大。

这一步的支持是全文中最省事的。因为我只在 Mac 上做了个验证，编译一次通过，没什么好说的。效果像这样：

图中你看到的 VSCode Debugger 背后可不是 V8，而是正经的 QuickJS 引擎噢。我也用 VSCode 调试过 Dart 和 C++ 的代码，当时我没有想到过这样的一套调试器该如何由一门第三方语言接入。搜索之后我发现，微软甚至已经为编辑器与任意第三方语言之间设计了一个名为 Debug Adapter Protocol 的通用调试协议，它很具备启发性。原来我觉得十分高大上的编程语言调试系统，也是能用断点、异常等概念来抽象化和结构化，并设计出通用协议的。微软在工程设计和文档上的积累真不是盖的，赞一个。

现在，我已经将这个支持 VSCode 调试的 QuickJS 版本编译到了 Miyoo 上，只是还没有做过实际的调试——有了定制内核驱动时不停给自己挖坑的教训，我现在自然不敢立 Flag 说它能用了（捂脸）

到此为止，本次实验所关注的能力都已经得到基本的验证了。相应的 Docker 镜像我也已发布到 GitHub，参见 MiyooSDK。也欢迎大家的交流。

这次写的又是一篇长文，这整套工作远没有文章写下来那么一气呵成，而是断断续续地逐步完成的。现在我手上的东西，还只是个初步的工程原型，有很多工作还可以继续深入。比如这些地方：

• 还不支持 USB 通信，不能 SSH 登录

• 还没有移植 JS 的上层框架

不过，只要有热情持续深入技术，那么收获一定不会让你失望。像大家眼里神秘的 Linux 内核，其实也是个有规可循的程序。即便是我这样本职写 JavaScript 的玩票选手，照样可以拿通用的科学方法论来实验分析它，而这个过程就像玩密室逃脱或者解谜游戏一样有趣——你知道问题一定能解决，只要用逻辑推理，找到房间里隐藏的那个开关就行。

我要特别感谢司徒，他为开源掌机的发展作出了巨大的贡献。这次最为疑难的硬件电路 bug，也是由他提供了关键信息后才最终得以解决的。很多时候我们缺的不是繁冗琐碎的入门指南，而是来自更高段位者，一两句话让你茅塞顿开的点拨。他就是这样一位令人尊敬的技术人。

这里跑个题，淘宝上有不少用司徒系统的名义销售掌机的店铺，这些商家其实已经与他本人完全无关了。虽然我仍然很推荐大家入手这个只要一百多块钱的 Miyoo 掌机用于娱乐或技术研究，但我还是有些感慨。所谓遍身罗绮者，不是养蚕人，大抵如此吧。

从搭建工具链到焊接电路板，再到定制 Linux 内核和 JS 引擎，这些技术本身固然都有点门槛。但富有乐趣的目标，总能让我们更有动力去克服中途的各种困难。我相信兴趣和热情总是最能刺激求知欲的，而永不知足的求知欲，才能驱动我们不停越过一个个山丘。毕竟乔帮主提过的那句名言是怎么说的来着？

我主要是个前端开发者。如果你对 Web 编辑器、WebGL 渲染、Hybrid 架构设计，或者计算机爱好者的碎碎念感兴趣，欢迎关注我噢 :)

扫码关注，干货内容第一时间给你