首先声明：这个绝对不是标题党！！！

不管是前端佬、后端佬、APP佬，还是普罗大众，都可以点进来借鉴看看。

反正经过这么一遭，我算是被醍醐灌顶了。

起因

因为会玩点大A票，所以日常会关注一些财经新闻。

而看新闻的几个渠道中，其中就有澎bo新闻或者经济学人。

吐个槽，不是外国的月亮比较圆，非得看他们，而是他们一些信息就是比村里的快！

言归正传！这些新闻机构好是好，但有一致命缺点：得花钱！

这你能忍？反正对于我这样苦哈哈的程序员，我的第一解决办法并不是直接付钱订购，而是想别的出路。

终于经过检索，我找到一条路子（具体是啥，相信大家都可以检索到）。

就这么一直用着用着，直到有一天，我脑子里蹦出个想法来。

经过

生成式对话AI可谓火遍大江南北，我就在想，我要是把链接喂给他们，是不是可以直接把文章拔下来，然后还可以将直接翻译好的文本给我？

秉承实干家的Title，说干就干。

我陆续验证了Deepseek、通义千问、ChatGTP、Grok、然后万恶的Grok😡😡...反正没有再使用其它的，我感觉已经可以了。

提示词基本都差不多，如下：

【https:// url 看官请假装这是一个链接^v^】，把这篇文章翻译成中文发给我。不需要整理

前四个都不行。基本是这样：

还有这样下面这样！！

终于，在遇到Grok这厮后，它直接明了的给出文章！

怀疑

回忆当时的Grok输出，我是直呼卧槽。

然后，细细看了下内容，有模有样，跟标题还真贴合。

然后，我质疑了。

是的，我是怀疑过的！！！

但，怀疑的方式依旧那么的愚蠢的。我怀疑的办法不是去说搞一篇原文，来作对比较，而是傻愣愣的直接去问Grok。

然后给我的回复就是：

他斩钉截铁的告诉我，不会也无法非法获取付费内容。

好吧。不管你这怎么样，

反正当时我信了。

我pua了我

就这么用了几天，感觉是真爽！狂喜了好长一段时间，每天会看一两篇。

倒不是一点怀疑都没有，而且怀疑的并不是内容有问题。

因为给出的内容，里面文章很有逻辑，还夹杂着数据支撑，最后还会给一些很犀利的结尾，跟之前阅读的那些内容，从感觉上真尼玛像！！！

其中真正让我有些疑虑的，是里面一些日期使用。比如今天明明是11月20日，已经星期四了，但里面的内容会出现：在11月19日，上周三的某知情人士说法。。，这样阐述。

但~因为相信，我自己pua我自己了，完全将其合理化了。

要么就认为是翻译的问题，或者认为时区的问题，再或者就认为AI翻译就这个尿性。

反转

最近关注过大A票的朋友，应该都知道半导体板块。然后也应该听说过安世半导体事件。

我就是其中关注者之一，也是其中的赌狗一只。

话说对于赌狗来说，最大的瘾就是在事情未确定的时候，去下注，然后为此获得收益。

那么应用到这个事件，我们就是去，下注WTKJ票，赌我们村里赢。

反正这个事件反反复复，那票也是起起落落。

就这么一天吧，某澎bo报道了一篇文章，然后一如往常将链接丢给Grok，反正Grok给出的内容大意就是：荷兰政府强硬，要坚定收回控制权。

好吧。赌狗看到这样消息，那自然而然想到对于WTKJ是利空。为了止损，所以夜间挂了跌停，为此还喜滋滋。

直到第二天，卖掉之后。我看到了国内新闻报道，内容跟Grok的那篇完全相反，是荷兰政府放弃干预！

嗯？咋回事？莫非国内消息滞后？（你看，这就是盲目的代价）

然后我又去看了一遍Grok内容，再次对比国内新闻。这截然相反的新闻，咋回事？？？

终于，我开窍一样的找回了原来的路子，用原文对比Grok一看！

吐血了！

跟原文真的半毛钱都没得关系。

你猜，我的反应是去干嘛？

我尽量是去质问那个Grok傻xxx，然后他的回复给我气笑了~

我是打死都没有去怀疑，你这浓眉大眼的AI你竟然就这么胡编乱造。

结局

好了，这个就是整个事情的经过。

事后的第一反应，是脑海里回忆起电影《2001太空漫游》那画面：

Open the pod bay doors,Hal. I'm sorry,Dave.

《2001太空漫游》的艺术高度再次飙升！

如果有一天，AI真得像人了，或者我们无法分辨他是真得或者假得，或者一百万个AI智能体都这么说得。那么我们怎么去辨别？

最后，告诫大家：

市场有风险，投资需谨慎！！！

你是小阿巴，刚入职的低级程序员，正在开发一个批量导入数据的程序。

没想到，程序刚上线，产品经理就跑过来说：小阿巴，用户反馈你的程序有 Bug，刚导入没多久就报错中断了！

你赶紧打开服务器，看着比你发量都少的报错信息：

你一脸懵逼：只有这点儿信息，我咋知道哪里出了问题啊？！

你只能硬着头皮让产品经理找用户要数据，然后一条条测试，看看是哪条数据出了问题……

原本大好的摸鱼时光，就这样无了。

这时，你的导师鱼皮走了过来，问道：小阿巴，你是持矢了么？脸色这么难看？

你无奈地说：皮哥，刚才线上出了个 bug，我花了 8 个小时才定位到问题……

鱼皮皱了皱眉：这么久？你没打日志吗？

你很是疑惑：谁是日志？为什么要打它？

鱼皮叹了口气：唉，难怪你要花这么久…… 来，我教你打日志！

⭐️ 本文对应视频版：bilibili.com/video/BV1K7…

什么是日志？

鱼皮打开电脑，给你看了一段代码：

@Slf4j

public class UserService {

   public void batchImport(List userList) {

       log.info("开始批量导入用户，总数：{}", userList.size());

       

       int successCount = 0;

       int failCount = 0;

       

       for (UserDTO userDTO : userList) {

           try {

               log.info("正在导入用户：{}", userDTO.getUsername());

               validateUser(userDTO);

               saveUser(userDTO);

               successCount++;

               log.info("用户 {} 导入成功", userDTO.getUsername());

          } catch (Exception e) {

               failCount++;

               log.error("用户 {} 导入失败，原因：{}", userDTO.getUsername(), e.getMessage(), e);

          }

      }

       

       log.info("批量导入完成，成功：{}，失败：{}", successCount, failCount);

  }

}

你看着代码里的 log.info、log.error，疑惑地问：这些 log 是干什么的？

鱼皮：这就是打日志。日志用来记录程序运行时的状态和信息，这样当系统出现问题时，我们可以通过日志快速定位问题。

你若有所思：哦？还可以这样！如果当初我的代码里有这些日志，一眼就定位到问题了…… 那我应该怎么打日志？用什么技术呢？

怎么打日志？

鱼皮：每种编程语言都有很多日志框架和工具库，比如 Java 可以选用 Log4j 2、Logback 等等。咱们公司用的是 Spring Boot，它默认集成了 Logback 日志框架，你直接用就行，不用再引入额外的库了~

日志框架的使用非常简单，先获取到 Logger 日志对象。

1）方法 1：通过 LoggerFactory 手动获取 Logger 日志对象：

public class MyService {

   private static final Logger logger = LoggerFactory.getLogger(MyService.class);

}

2）方法 2：使用 this.getClass 获取当前类的类型，来创建 Logger 对象：

public class MyService {

   private final Logger logger = LoggerFactory.getLogger(this.getClass());

}

然后调用 logger.xxx（比如 logger.info）就能输出日志了。

public class MyService {

   private final Logger logger = LoggerFactory.getLogger(this.getClass());



   public void doSomething() {

       logger.info("执行了一些操作");

  }

}

效果如图：

小阿巴：啊，每个需要打日志的类都要加上这行代码么？

鱼皮：还有更简单的方式，使用 Lombok 工具库提供的 @Slf4j 注解，可以自动为当前类生成日志对象，不用手动定义啦。

@Slf4j

public class MyService {

   public void doSomething() {

       log.info("执行了一些操作");

  }

}

上面的代码等同于 “自动为当前类生成日志对象”：

private static final org.slf4j.Logger log = 

   org.slf4j.LoggerFactory.getLogger(MyService.class);

你咧嘴一笑：这个好，爽爽爽！

等等，不对，我直接用 Java 自带的 System.out.println 不也能输出信息么？何必多此一举？

System.out.println("开始导入用户" + user.getUsername());

鱼皮摇了摇头：千万别这么干！

首先，System.out.println 是一个同步方法，每次调用都会导致耗时的 I/O 操作，频繁调用会影响程序的性能。

而且它只能输出信息到控制台，不能灵活控制输出位置、输出格式、输出时机等等。比如你现在想看三天前的日志，System.out.println 的输出早就被刷没了，你还得浪费时间找半天。

你恍然大悟：原来如此！那使用日志框架就能解决这些问题吗？

鱼皮点点头：没错，日志框架提供了丰富的打日志方法，还可以通过修改日志配置文件来随心所欲地调教日志，比如把日志同时输出到控制台和文件中、设置日志格式、控制日志级别等等。

在下苦心研究日志多年，沉淀了打日志的 8 大邪修秘法，先传授你 2 招最基础的吧。

打日志的 8 大最佳实践

1、合理选择日志级别

第一招，日志分级。

你好奇道：日志还有级别？苹果日志、安卓日志？

鱼皮给了你一巴掌：可不要乱说，日志的级别是按照重要程度进行划分的。

其中 DEBUG、INFO、WARN 和 ERROR 用的最多。

• 调试用的详细信息用 DEBUG
• 正常的业务流程用 INFO
• 可能有问题但不影响主流程的用 WARN
• 出现异常或错误的用 ERROR

log.debug("用户对象的详细信息：{}", userDTO);  // 调试信息

log.info("用户 {} 开始导入", username);  // 正常流程信息

log.warn("用户 {} 的邮箱格式可疑，但仍然导入", username);  // 警告信息

log.error("用户 {} 导入失败", username, e);  // 错误信息

你挠了挠头：俺直接全用 DEBUG 不行么？

鱼皮摇了摇头：如果所有信息都用同一级别，那出了问题时，你怎么快速找到错误信息？

在生产环境，我们通常会把日志级别调高（比如 INFO 或 WARN），这样 DEBUG 级别的日志就不会输出了，防止重要信息被无用日志淹没。

你点点头：俺明白了，不同的场景用不同的级别！

2、正确记录日志信息

鱼皮：没错，下面教你第二招。你注意到我刚才写的日志里有一对大括号 {} 吗？

log.info("用户 {} 开始导入", username);

你回忆了一下：对哦，那是啥啊？

鱼皮：这叫参数化日志。{} 是一个占位符，日志框架会在运行时自动把后面的参数值替换进去。

你挠了挠头：我直接用字符串拼接不行吗？

log.info("用户 " + username + " 开始导入");

鱼皮摇摇头：不推荐。因为字符串拼接是在调用 log 方法之前就执行的，即使这条日志最终不被输出，字符串拼接操作还是会执行，白白浪费性能。

你点点头：确实，而且参数化日志比字符串拼接看起来舒服~

鱼皮：没错。而且当你要输出异常信息时，也可以使用参数化日志：

try {

   // 业务逻辑

} catch (Exception e) {

   log.error("用户 {} 导入失败", username, e);  // 注意这个 e

}

这样日志框架会同时记录上下文信息和完整的异常堆栈信息，便于排查问题。

你抱拳：学会了，我这就去打日志！

3、把控时机和内容

很快，你给批量导入程序的代码加上了日志：

@Slf4j

public class UserService {

   public BatchImportResult batchImport(List userList) {

       log.info("开始批量导入用户，总数：{}", userList.size());

       int successCount = 0;

       int failCount = 0;

       for (UserDTO userDTO : userList) {

           try {

               log.info("正在导入用户：{}", userDTO.getUsername());   

               // 校验用户名

               if (StringUtils.isBlank(userDTO.getUsername())) {

                   throw new BusinessException("用户名不能为空");

              }

               // 保存用户

               saveUser(userDTO);

               successCount++;

               log.info("用户 {} 导入成功", userDTO.getUsername());

          } catch (Exception e) {

               failCount++;

               log.error("用户 {} 导入失败，原因：{}", userDTO.getUsername(), e.getMessage(), e);

          }

      }

       log.info("批量导入完成，成功：{}，失败：{}", successCount, failCount);

       return new BatchImportResult(successCount, failCount);

  }

}

光做这点还不够，你还翻出了之前的屎山代码，想给每个文件都打打日志。

但打着打着，你就不耐烦了：每段代码都要打日志，好累啊！但是不打日志又怕出问题，怎么办才好？

鱼皮笑道：好问题，这就是我要教你的第三招 —— 把握打日志的时机。

对于重要的业务功能，我建议采用防御性编程，先多多打日志。比如在方法代码的入口和出口记录参数和返回值、在每个关键步骤记录执行状态，而不是等出了问题无法排查的时候才追悔莫及。之后可以再慢慢移除掉不需要的日志。

你叹了口气：这我知道，但每个方法都打日志，工作量太大，都影响我摸鱼了！

鱼皮：别担心，你可以利用 AOP 切面编程，自动给每个业务方法的执行前后添加日志，这样就不会错过任何一次调用信息了。

你双眼放光：这个好，爽爽爽！

鱼皮：不过这样做也有一个缺点，注意不要在日志中记录了敏感信息，比如用户密码。万一你的日志不小心泄露出去，就相当于泄露了大量用户的信息。

你拍拍胸脯：必须的！

4、控制日志输出量

一个星期后，产品经理又来找你了：小阿巴，你的批量导入功能又报错啦！而且怎么感觉程序变慢了？

你完全不慌，淡定地打开服务器的日志文件。结果瞬间呆住了……

好家伙，满屏都是密密麻麻的日志，这可怎么看啊？！

鱼皮看了看你的代码，摇了摇头：你现在每导入一条数据都要打一些日志，如果用户导入 10 万条数据，那就是几十万条日志！不仅刷屏，还会影响性能。

你有点委屈：不是你让我多打日志的么？那我应该怎么办？

鱼皮：你需要控制日志的输出量。

1）可以添加条件来控制，比如每处理 100 条数据时才记录一次：

if ((i + 1) % 100 == 0) {

   log.info("批量导入进度：{}/{}", i + 1, userList.size());

}

2）或者在循环中利用 StringBuilder 进行字符串拼接，循环结束后统一输出：

StringBuilder logBuilder = new StringBuilder("处理结果：");

for (UserDTO userDTO : userList) {

   processUser(userDTO);

   logBuilder.append(String.format("成功[ID=%s], ", userDTO.getId()));

}

log.info(logBuilder.toString());

3）还可以通过修改日志配置文件，过滤掉特定级别的日志，防止日志刷屏：

<appender name="FILE" class="ch.qos.logback.core.FileAppender">

   <file>logs/app.logfile>

   

   <filter class="ch.qos.logback.classic.filter.ThresholdFilter">

       <level>INFOlevel>

   filter>

appender>

5、统一日志格式

你开心了：好耶，这样就不会刷屏了！但是感觉有时候日志很杂很乱，尤其是我想看某一个请求相关的日志时，总是被其他的日志干扰，怎么办？

鱼皮：好问题，可以在日志配置文件中定义统一的日志格式，包含时间戳、线程名称、日志级别、类名、方法名、具体内容等关键信息。

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">

   <encoder>

       

       <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%npattern>

   encoder>

appender>

这样输出的日志更整齐易读：

此外，你还可以通过 MDC（Mapped Diagnostic Context）给日志添加额外的上下文信息，比如请求 ID、用户 ID 等，方便追踪。

在 Java 代码中，可以为 MDC 设置属性值：

@PostMapping("/user/import")

public Result importUsers(@RequestBody UserImportRequest request) {

   // 1. 设置 MDC 上下文信息

   MDC.put("requestId", generateRequestId());

   MDC.put("userId", String.valueOf(request.getUserId()));

   try {

       log.info("用户请求处理完成");      

       // 执行具体业务逻辑

       userService.batchImport(request.getUserList());     

       return Result.success();

  } finally {

       // 2. 及时清理MDC（重要！）

       MDC.clear();

  }

}

然后在日志配置文件中就可以使用这些值了：

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">

   <encoder>

       

       <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - [%X{requestId}] [%X{userId}] %msg%npattern>

   encoder>

appender>

这样，每个请求、每个用户的操作一目了然。

6、使用异步日志

你又开心了：这样打出来的日志，确实舒服，爽爽爽！但是我打日志越多，是不是程序就会更慢呢？有没有办法能优化一下？

鱼皮：当然有，可以使用 异步日志。

正常情况下，你调用 log.info() 打日志时，程序会立刻把日志写入文件，这个过程是同步的，会阻塞当前线程。而异步日志会把写日志的操作放到另一个线程里去做，不会阻塞主线程，性能更好。

你眼睛一亮：这么厉害？怎么开启？

鱼皮：很简单，只需要修改一下配置文件：

<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">

   <queueSize>512queueSize>  

   <discardingThreshold>0discardingThreshold>  

   <neverBlock>falseneverBlock>  

   <appender-ref ref="FILE" />  

appender>

<root level="INFO">

   <appender-ref ref="ASYNC" />

root>

不过异步日志也有缺点，如果程序突然崩溃，缓冲区中还没来得及写入文件的日志可能会丢失。

所以要权衡一下，看你的系统更注重性能还是日志的完整性。

你想了想：我们的程序对性能要求比较高，偶尔丢几条日志问题不大，那我就用异步日志吧。

7、日志管理

接下来的很长一段时间，你混的很舒服，有 Bug 都能很快发现。

你甚至觉得 Bug 太少、工作没什么激情，所以没事儿就跟新来的实习生阿坤吹吹牛皮：你知道日志么？我可会打它了！

直到有一天，运维小哥突然跑过来：阿巴阿巴，服务器挂了！你快去看看！

你连忙登录服务器，发现服务器的硬盘爆满了，没法写入新数据。

你查了一下，发现日志文件竟然占了 200GB 的空间！

你汗流浃背了，正在考虑怎么甩锅，结果阿坤突然鸡叫起来：阿巴 giegie，你的日志文件是不是从来没清理过？

你尴尬地倒了个立，这样眼泪就不会留下来。

鱼皮叹了口气：这就是我要教你的下一招 —— 日志管理。

你好奇道：怎么管理？我每天登服务器删掉一些历史文件？

鱼皮：人工操作也太麻烦了，我们可以通过修改日志配置文件，让框架帮忙管理日志。

首先设置日志的滚动策略，可以根据文件大小和日期，自动对日志文件进行切分。

<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">

   <fileNamePattern>logs/app-%d{yyyy-MM-dd}.%i.logfileNamePattern>

   <maxFileSize>10MBmaxFileSize>

   <maxHistory>30maxHistory>

rollingPolicy>

这样配置后，每天会创建一个新的日志文件（比如 app-2025-10-23.0.log），如果日志文件大小超过 10MB 就再创建一个（比如 app-2025-10-23.1.log），并且只保留最近 30 天的日志。

还可以开启日志压缩功能，进一步节省磁盘空间：

<rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">

   

   <fileNamePattern>logs/app-%d{yyyy-MM-dd}.log.gzfileNamePattern>

rollingPolicy>

你有些激动：吼吼，这样我们就可以按照天数更快地查看日志，服务器硬盘也有救啦！

8、集成日志收集系统

两年后，你负责的项目已经发展成了一个大型的分布式系统，有好几十个微服务。

如今，每次排查问题你都要登录到不同的服务器上查看日志，非常麻烦。而且有些请求的调用链路很长，你得登录好几台服务器、看好几个服务的日志，才能追踪到一个请求的完整调用过程。

你简直要疯了！

于是你找到鱼皮求助：现在查日志太麻烦了，当年你还有一招没有教我，现在是不是……

鱼皮点点头：嗯，对于分布式系统，就必须要用专业的日志收集系统了，比如很流行的 ELK。

你好奇：ELK 是啥？伊拉克？

阿坤抢答道：我知道，就是 Elasticsearch + Logstash + Kibana 这套组合。

简单来说，Logstash 负责收集各个服务的日志，然后发送给 Elasticsearch 存储和索引，最后通过 Kibana 提供一个可视化的界面。

这样一来，我们可以方便地集中搜索、查看、分析日志。

你惊讶了：原来日志还能这么玩，以后我所有的项目都要用 ELK！

鱼皮摆摆手：不过 ELK 的搭建和运维成本比较高，对于小团队来说可能有点重，还是要按需采用啊。

结局

至此，你已经掌握了打日志的核心秘法。

只是你很疑惑，为何那阿坤竟对日志系统如此熟悉？

阿坤苦笑道：我本来就是日志管理大师，可惜我上家公司的同事从来不打日志，所以我把他们暴打了一顿后跑路了。

阿巴 giegie 你要记住，日志不是写给机器看的，是写给未来的你和你的队友看的！

你要是以后不打日志，我就打你！

更多

💻 编程学习交流：编程导航 📃 简历快速制作：老鱼简历 ✏️ 面试刷题神器：面试鸭

大家好，我是 Java陈序员。

你是否遇到过：在公共电脑上想临时用微信却担心账号安全，服务器或 Linux 系统上找不到合适的微信客户端，或者想在多个设备上便捷访问微信却受限于安装环境？

今天，给大家介绍一个超实用的开源项目，让你通过浏览器就能轻松使用微信，无需在本地安装客户端！

项目介绍

wechat-selkies —— 基于 Docker 的微信/QQ Linux 客户端，将官方微信/QQ Linux 客户端封装在容器中，借助 Selkies WebRTC 技术，实现了通过浏览器直接访问使用。

功能特色：

• 浏览器访问：通过 Web 浏览器直接使用微信，无需本地安装
• Docker化部署：简单的容器化部署，环境隔离
• 数据持久化：支持配置和聊天记录持久化存储
• 中文支持：完整的中文字体和本地化支持，支持本地中文输入法
• 图片复制：支持通过侧边栏面板开启图片复制
• 文件传输：支持通过侧边栏面板进行文件传输
• AMD64和ARM64架构支持：兼容主流CPU架构
• 硬件加速：可选的 GPU 硬件加速支持
• 窗口切换器：左上角增加切换悬浮窗，方便切换到后台窗口，为后续添加其它功能做基础
• 自动启动：可配置自动启动微信和QQ客户端（可选）

技术栈：

• 基础镜像：ghcr.io/linuxserver/baseimage-selkies:ubuntunoble
• 微信客户端：官方微信 Linux 版本
• Web 技术：Selkies WebRTC
• 容器化：Docker + Docker Compose

安装部署

环境要求

• Docker
• Docker Compose
• 支持 WebRTC 的现代浏览器（Chrome、Firefox、Safari 等）

Docker 部署

1、拉取镜像

# GitHub Container Registry 镜像

docker pull ghcr.io/nickrunning/wechat-selkies:latest



# Docker Hub 镜像

docker pull ghcr.io/nickrunning/wechat-selkies:latest

2、创建挂载目录

mkdir -p /data/software/wechat/conf

3、运行容器

docker run -it -d \

	-p 3000:3000 \

	-p 3001:3001 \

	-v /data/software/wechat/conf:/config \

	--device /dev/dri:/dev/dri \

	nickrunning/wechat-selkies:latest

4、容器运行成功后，浏览器访问

# HTTP

http://{ip/域名}:3000



# HTTPS

https://{ip/域名}:3001

注意：映射 3000 端口用于 HTTP 访问，3001 端口用于 HTTPS 访问，建议使用 HTTPS.

Docker Compose 部署

1、创建项目目录并进入

mkdir -p /data/software/wechat-selkies

cd /data/software/wechat-selkies

2、创建 docker-compose.yaml 文件

 services:

   wechat-selkies:

     image: nickrunning/wechat-selkies:latest    # or ghcr.io/nickrunning/wechat-selkies:latest

     container_name: wechat-selkies

     ports:

       - "3000:3000"       # http port

       - "3001:3001"       # https port

     restart: unless-stopped

     volumes:

       - ./config:/config

     devices:

       - /dev/dri:/dev/dri # optional, for hardware acceleration

     environment:

       - PUID=1000                    # user ID

       - PGID=100                     # group ID

       - TZ=Asia/Shanghai             # timezone

       - LC_ALL=zh_CN.UTF-8           # locale

       - AUTO_START_WECHAT=true       # default is true

       - AUTO_START_QQ=false          # default is false

       # - CUSTOM_USER=      # recommended to set a custom user name

       # - PASSWORD=     # recommended to set a password for selkies web ui

3、启动服务

docker-compose up -d

4、运行成功后，浏览器访问

# HTTP

http://{ip/域名}:3000



# HTTPS

https://{ip/域名}:3001

源码部署

1、克隆或下载项目源码

git clone https://github.com/nickrunning/wechat-selkies.git

cd wechat-selkies

2、启动服务

docker-compose up -d

3、运行成功后，浏览器访问

# HTTP

http://{ip/域名}:3000



# HTTPS

https://{ip/域名}:3001

配置说明

在 docker-compose.yml 中可以配置以下环境变量：

功能体验

wechat-selkies 部署成功后，即可通过浏览器访问。

1、打开地址后，需要使用手机微信进行扫码登录

2、扫码登录成功后，即可开始使用

3、同时支持暗黑主题模式

4、QQ 同样也需要进行扫码登录或者使用账密登录

5、登录成功后，即可开始使用

如果你想在 Linux 系统使用微信或者想随时随地便捷使用微信，不妨试试 wechat-selkies, 可以使用 Docker 快速地部署在服务器上，快去试试吧~

项目地址：https://github.com/nickrunning/wechat-selkies

最后

推荐的开源项目已经收录到 GitHub 项目，欢迎 Star：

https://github.com/chenyl8848/great-open-source-project

或者访问网站，进行在线浏览：

https://chencoding.top:8090/#/

大家的点赞、收藏和评论都是对作者的支持，如文章对你有帮助还请点赞转发支持下，谢谢！

点击上方亿元程序员+关注和★星标

引言

哈喽大家好，不知道小伙伴们最近有没有关注到一个名叫《逃离鸭科夫》的游戏。

这款游戏在各大社交平台和游戏社区都成为了热门话题，Steam平台上的同时在线人数一度突破30万，其口碑表现也相当出色。

在累计一万七千多条玩家评价中，收获了96%的压倒性好评，整体评价明显优于今年发布的多数新作。

其中更为炸裂的信息，开发这款游戏的团队仅仅只有5个人。

除了有常规的3D美术和数值策划外，还有3个神人：

• 负责游戏设计、战斗编程以及基础美术的制作人。
• 负责游戏内大部分编程的游戏主策。
• 负责游戏内所有美术资产的校招生。

更想不到的是，如此精简的团队，打造出的游戏，仅仅2周时间，收获1个亿，远高于团队预期。

那么问题来了，鸭科夫如此成功，我们可以做一个“鸡科夫”吗？

这个问题还是交给小伙伴们吧，笔者实在是折腾不起，但是呢，我们可以定个小目标，做个简单的小东西起步。

言归正传，本期笔者介绍一下如何在Cocos游戏开发中，制作类似逃离鸭科夫中的激光瞄准器！

本文源码和源工程在文末获取，小伙伴们自行前往。

什么是激光瞄准器？

激光瞄准器是一种安装在武器（如枪支、弓箭等）上的装置，它发射出一束低功率的、可见或不可见的激光束，在被瞄准的物体上投射一个光点，提示使用者弹着点（即子弹预计会命中的位置）。

制作原理

在Cocos游戏开发中，激光瞄准器的制作方法有不少，包括但不限于以下几种：

• Line组件。
• 自定义Shader。
• 粒子系统。

本期我们主要演示Line组件的使用。

Line组件

Line组件用于渲染3D场景中给定的点连成的线段。

Line组件渲染的线段是有宽度的，并且总是面向摄像机，这与billboard组件相似。

Line组件的使用非常简单，我们重点关注他的:

• positions: 每个线段端点的坐标。
• width: 线段宽度，如果采用曲线，则表示沿着线段方向上的曲线变化。
• color: 线段颜色，如果采用渐变色，则表示沿着线段方向上的颜色渐变。

激光瞄准器制作实例

下面跟随这笔者，一起在Cocos游戏开发中实现一个激光瞄准器。

1.资源准备

老生常谈，有美术搭子的找美术搭子，没有美术搭子的找AI搭子。

笔者拿出做例子最爱的小鸡，本期我们叫他“鸡科夫”。

2.Line组件

新建一个节点，绑定一个Line组件，设置一下线的宽度和颜色，坐标我们在代码中动态设置。

3.写代码

首先声明一个ChickenKF类并挂在Canvas上，绑定好Line组件、鸡科夫和摄像机。

然后监听一下鼠标事件，按下时显示激光，移动瞄准，抬起时关闭激光。

通过鼠标事件和射线检测，确定激光的方向和目标。

计算出来激光的起点和终点，对Line组件的positions进行赋值。

4.效果演示

结语

逃离鸭科夫之所以能够成为爆款，并非偶然，它源于对游戏的热爱、对玩家的重视以及对游戏的执着，因为他们“听人劝吃饱饭”。

假如我们完整复刻出来一个“鸡科夫”，它会如愿成为爆款吗？

评论区说出你的看法。

本文源工程可通过私信发送 ChickenKF 获取。

我是"亿元程序员"，一位有着8年游戏行业经验的主程。在游戏开发中，希望能给到您帮助, 也希望通过您能帮助到大家。

AD:笔者线上的小游戏《打螺丝闯关》《贪吃蛇掌机经典》《重力迷宫球》《填色之旅》《方块掌机经典》大家可以自行点击搜索体验。

实不相瞒，想要个赞和爱心！请把该文章分享给你觉得有需要的其他小伙伴。谢谢！

推荐专栏：

知识付费专栏

你知道和不知道的微信小游戏常用API整理，赶紧收藏用起来~

100个Cocos实例

8年主程手把手打造Cocos独立游戏开发框架

和8年游戏主程一起学习设计模式

从零开始开发贪吃蛇小游戏到上线系列

点击下方灰色按钮+关注。

大家好，我来了🙂。

我们团队，维护着一个有5年历史的史诗级中后台项目😖。在这座屎山里，有一个叫handleOrderSubmit.js的文件。

可以下载瞧一瞧 有多屎👉 handleOrderSubmit.js

它是一个长达500多行的React useEffect 钩子函数（是的，你没看错，一个useEffect）。

它混合了订单数据的本地校验、价格计算、优惠券应用、API请求、全局状态更新、以及错误弹窗处理... 所有的逻辑，都塞在一个函数里，用if/else和try/catch层层嵌套。

没人敢动它😖。

每次产品经理提一个小需求，比如在提交订单时，增加一种新的优惠券类型，我们整个团队的表情都像被雷劈了。因为我们知道，改这个函数，要么加班一周，要么就等着P0级事故。

上周，产品经理要求我们在这个函数里，加入一个全新的风控逻辑。

我评估了一下，手动重构，至少需要一个资深工程师一周的时间，而且风险极大。

我受够了。我决定，把这个烫手的任务，扔给我的实习生——AI（我用的是GPT-5 mini，穷😂）。

这篇文章，就是我人机协作，啃下这块硬骨头的完整复盘，大家继续看。

我不能直接说重构它

我犯的第一个错误，是直接把500行代码贴给AI，然后说：帮我重构这段代码。

AI很听话，它给我的，是一段看起来更整洁的代码——它把if/else换成了switch，提了几个变量... 这不叫重构，这叫重新排版，毫无意义。

我很快意识到：AI是一个能力超强、但没有灵魂的执行者。我，作为开发者，必须给它提供一个清晰的方案。

于是，我制定了一个五步重构法。

我的Prompt和思考

我的核心思想是：AI负责执行，我负责决策。 我要像一个指挥家一样，一步一步地引导AI，把这500行的代码，拆解成高内聚、低耦合的模块。

第一步：先让AI读懂屎山

我不能上来就让AI改。我得先确认，它和我对这段代码的理解，在一个频道上。

Prompt：

你是一个资深的React架构师。请分析下面这段500行的useEffect代码。

1. 告诉我它做了几件主要的事情？（职责分析）
2. 找出所有的副作用（比如API请求、localStorage操作、全局状态更新）。
3. 找出所有的纯逻辑（比如数据校验、价格计算）。
4. 评价它的可维护性和可测试性。

GPT的回答，给了我一个惊喜。它清晰地列出了：

很好，AI看懂了！我们就可以可以开始了😁。

第二步：先分离纯逻辑代码

这是最关键的一步。我要把计算和动作分开。

Prompt：

非常好。现在，请你只针对纯逻辑部分（表单校验、价格计算）进行重构。

1. 把这些逻辑，从原函数中提取出来，变成独立的、可导出的纯函数。
2. 这些函数必须是纯的：不能有任何副作用（不能调用api或setLoading）。
3. 使用TypeScript，为这些新函数的入参和返回值，提供清晰的类型定义。

AI立刻唰唰唰地给了我几个文件：

validate.ts:

export function validateOrder(formData: OrderForm): string | null {

  if (!formData.user) return '用户信息不能为空';

  if (formData.items.length === 0) return '商品不能为空';

  // ... 10 more rules

  return null;

}

calculator.ts:

export function calculateTotalPrice(items: Item[], coupon: Coupon): number {

  let total = items.reduce((sum, item) => sum + item.price * item.quantity, 0);

  if (coupon.type === 'PERCENT') {

    total *= (1 - coupon.value / 100);

  }

  // ... 20 more rules

  return total;

}

第三步：让AI为自己的代码做测试

我怎么知道AI提炼的逻辑，是对的还是错的？ 答案：让它自己写单元测试来证明。

Prompt：

你现在是一个QA工程师。请使用Vitest，为你刚才提取的validateOrder和calculateTotalPrice这两个函数，编写全面的单元测试用例。 必须覆盖所有边界情况，包括正常、异常、和边缘值。

AI再次给了我惊喜。它生成的测试用例，比我手写的还要全：

// calculator.test.ts

import { describe, it, expect } from 'vitest';

import { calculateTotalPrice } from './calculator';



describe('calculateTotalPrice', () => {

  it('should return 0 for empty cart', () => {

    expect(calculateTotalPrice([], null)).toBe(0);

  });

  

  it('should apply percent coupon', () => {

    const items = [{ price: 100, quantity: 1 }];

    const coupon = { type: 'PERCENT', value: 10 };

    expect(calculateTotalPrice(items, coupon)).toBe(90);

  });

  // ... 省略更多

});

我把这些测试用例跑了一遍，全部通过。我现在信心大增😁。

第四步：重写协调层

现在，纯逻辑已经被分离并验证了。原来的500行屎山，只剩下副作用和流程控制代码了。是时候重写它了。

Prompt：

干得漂亮。现在，我们来重构那个原始的useEffect函数。

1. 它现在唯一的职责是协调。
2. 调用我们刚才创建的validateOrder和calculateTotalPrice纯函数。
3. 把所有的副作用（API请求、setLoading、showToast）清晰地编排起来。
4. 使用async/await，让异步流程更清晰，用try/catch处理错误。

这次，AI给我的，是一个只有30行左右的、清晰的流程代码：

// 重构后的 useEffect

useEffect(() => {

  const submitOrder = async () => {

    setLoading(true);

    try {

      // 1. 协调：验证 (纯)

      const errorMsg = validateOrder(formData);

      if (errorMsg) {

        showToast(errorMsg);

        return;

      }

      

      // 2. 协调：计算 (纯)

      const totalPrice = calculateTotalPrice(formData.items, formData.coupon);



      // 3. 协调：副作用（不纯）

      const result = await api.post('/order/submit', { ...formData, totalPrice });

      

      // 4. 协调：响应（不纯）

      if (result.code === 200) {

        showToast('订单提交成功！');

        router.push('/success');

      } else {

        showToast(result.message);

      }

    } catch (err) {

      showToast(err.message);

    } finally {

      setLoading(false);

    }

  };



  if (isSubmitting) { // 假设一个触发条件

    submitOrder();

    setIsSubmitting(false);

  }

}, [isSubmitting, formData /* ...其他依赖 */]);

第五步：最后守卫工作，加入新功能

别忘了，我重构的目的，是为了加风控这个新功能。

Prompt：

最后一步。请在API请求之前，加入一个风控检查的逻辑（调用riskControl.check(...)）。这是一个异步函数，如果检查不通过，它会抛出一个错误。

AI在第2步和第3步之间，加了几行代码，完美收工。

这次重构，我总共花了大概5个小时，而不是原计划的一周。

总觉得 AI 不会淘汰会写代码的工程师。

只会降维打击那些只会堆砌代码的工程师。

那段500行的屎山，在过去，是我的噩梦；现在，有了AI的帮助，它变成了我的靶场。

这种感觉，真爽🙌。

你是小阿巴，一位没有对象的程序员。

这天深夜，你打开了某个颜色网站，准备鉴赏一些精彩的视频教程。

结果一个大大的付费弹窗阻挡了你！

你心想：可恶，为啥颜色网站都要收费啊？

作为一名程序员，你怎能甘心？

于是你决定自己做一个，不就是上传视频、播放视频嘛？

这时，经常给大家分享 AI 和编程知识的 鱼皮 突然从你身后冒了出来：天真！你知道自己做一个要花多少钱么？

你吓了一跳：我又没做过这种网站，怎么知道要花多少？

难道，你做过？

鱼皮一本正经：哼，当然…… 没有。

不过我做过可以看视频的、技术栈完全类似的 编程学习网站，所以很清楚这类网站的成本。

你来了兴趣：哦？愿闻其详。

鱼皮笑了笑：那我就以 编程导航 项目为例，从网站开发、上线到运营的完整流程，给你算算做一个视频网站到底要花多少钱。还能教你怎么省钱哦~

你点了个赞，并递上了两个硬币：好啊，快说快说！

鱼皮特别感谢朋友们的支持，你们的鼓励是我持续创作的动力 🌹！

⚠️ 友情声明：以下成本是基于个人经验 + 专业云服务商价格的估算（不考虑折扣），仅供参考。

⭐️ 推荐观看本文对应视频版：bilibili.com/video/BV1nJ…

服务器

想让别人访问你的网站，首先你要有一台服务器。

你点点头：我知道，代码文件都要放到服务器上运行，用户通过浏览器访问网站，其实是在向服务器请求网页文件和数据。

那服务器怎么选呢？

鱼皮：服务器的配置要看你的网站规模。刚开始做个小型视频网站，可以用入门配置的轻量应用服务器 （比如 2 核 CPU、2G 内存、4M 带宽） ，一年几百块就够了。

等后续用户多了，服务器带宽跟不上了再升级。比如 4 核 CPU、16G 内存、14M 带宽，一年差不多几千块。

你：几百块？比我想的便宜啊。

鱼皮：没错，国内云服务现在竞争很激烈、动不动就搞优惠。

但是要注意，如果你想做 “那种网站”，就要考虑用海外服务器了（好处是不用备案）。

咳咳，我们不谈这个……

数据库

有了服务器，还得有数据库，用来存储网站的用户信息、视频信息、评论点赞这些数据。

你：这个简单，数据库不就是 MySQL、PostgreSQL 这些嘛，装在服务器上不就行了？

鱼皮：是可以的，但我更建议使用云数据库服务，比如阿里云 RDS 或者腾讯云的云数据库。

你：为啥？不是要多花钱吗？

鱼皮：因为云数据库更稳定，而且自带备份、容灾、监控这些功能，你自己搞的话，还要费时费力安装维护，万一数据丢了可就麻烦了。

你：确实，那得多少钱？

鱼皮：入门级的云数据库（比如 2 核 4G 内存、100GB 硬盘）包年大概 2000 元左右。后面用户多了、数据量大了，就要升级配置（比如 4 核 16G），那一年就要 1 万多了。不过那个时候你已经赚麻了……

Redis

鱼皮：对了，我还建议你加个 Redis 缓存。

你挠了挠头：Redis？之前看过你的 讲解视频。这个是必须的吗？

鱼皮：刚开始可以没有，但如果你想让网站数据能更快加载，强烈建议用。

你想啊，视频网站用户一进来都要查看视频列表、热门推荐这些，如果用 Redis 把热点数据缓存起来，响应速度能快好几倍，还能帮数据库分摊查询压力。

你：确实，网站更快用户更爽，也更愿意付费。那 Redis 要多少钱？

鱼皮：Redis 比数据库便宜一些。入门级的 Redis 服务一年大概 1000 元左右。

你松了口气：也还行吧，看来做个视频网站也花不了多少钱啊！

对象存储

鱼皮：别急，接下来才是重点！

我问问你，视频文件保存在哪儿？

你不假思索：当然是存在服务器的硬盘上！

鱼皮哈哈大笑：别开玩笑了，一个高清视频动不动就几百 MB 甚至几个 G，你那点儿服务器硬盘能存几个视频？

而且服务器带宽有限，如果同时有很多用户看视频，服务器根本撑不住！

你：那咋办啊！

鱼皮：更好的做法是用 对象存储，比如阿里云 OSS、腾讯云 COS。

对象存储是专门用来存海量文件的云服务，它容量几乎无限、可以弹性扩展，而且访问速度快、稳定性高，很适合存储图片和音视频这些大文件。

你：贵吗？

鱼皮：存储本身不贵，100GB 一年也就几十块钱。但 真正贵的是流量费用！

用户每看一次视频，都要从对象存储下载数据，这就产生了流量。

如果一个 1 GB 的视频被完整播放 1000 次，那就是 1000 GB 的流量，大概 500 块钱。

你看那些视频网站，每天光 1 个视频可能就有 10 万人看过，价格可想而知。

你惊讶地说不出话来：阿巴阿巴……

视频转码

鱼皮接着说：这还不够！对于视频网站，你还要做 视频转码。因为用户上传的视频格式、分辨率、编码方式都不一样，你需要把它们统一转成适合网页播放的格式，还要生成不同清晰度的版本让用户选择（标清、高清、超清）。

你：啊，那不是要多存好几个不同清晰度的视频文件？

鱼皮：没错，而且转码本身也是要钱的！

一般按照清晰度和视频分钟数计费。如果你上传 1000 个小时的高清视频，光转码费就得几千块！

CDN 加速

你急了：怎么做个视频网站处处都要花钱啊！有没有便宜点的办法？

鱼皮笑道：可以用 CDN。

你：CDN是啥？听着就高级！

鱼皮：CDN 叫内容分发网络，简单说就是把你的视频缓存到全国各地的服务器节点上。用户看视频的时候，从最近的节点拿数据，不仅速度更快，而且流量费比对象存储便宜不少。

你眼睛一亮：这么好？那不是必用 CDN！

鱼皮：没错，一般建议对象存储配合 CDN 使用。

而且视频网站 一定要做好流量防刷和安全防护！

现在有的平台自带了流量防盗刷功能：

此外，建议手动添加更多流量安全配置。

1）设置访问频率限制，防止短时间被盗刷大量流量

2）还要配置 CDN 的流量告警，超过阈值及时得到通知

3）还要启用 referer 防盗链，防止别人盗用你的视频链接，用你的流量做网站捞钱。

如果不做这些，可能分分钟给你刷破产了！

你：这我知道，之前看过很多你破产和被攻击的视频！

鱼皮：我 ***！

视频点播

你：为了给用户看个视频，我要先用对象存储保存文件、再通过云服务转码视频、再通过 CDN 给用户加速访问，感觉很麻烦啊！

鱼皮神秘一笑：嘿嘿，其实还有更简单的方案 —— 视频点播服务，这是快速实现视频网站的核心。

只需要通过官方提供的 SDK 代码包和示例代码，就能快速完成视频上传、转码、多清晰度切换、加密保护等功能。

此外，还提供了 CDN 内容加速和各端的视频播放器。

你双眼放光：这么厉害，如果我自己从零开发这些功能，至少得好几个月啊！

鱼皮：没错，视频点播服务相当于帮你做了整合，能大幅提高开发效率。

但是它的费用也包含了存储费、转码费和流量费，价格跟前面提到的方案不相上下。

你叹了口气：唉，主要还是流量费太贵了啊……

网站上线还要准备啥？

鱼皮：讲完了开发视频网站需要的技术，接下来说说网站上线还需要的其他东西。

你：啊？还有啥？

鱼皮：首先，你得有个 域名 给用户访问吧？总不能让人家记你的 IP 地址吧？

不过别担心，普通域名一年也就几十块钱（比如我的 codefather.cn 才 38 / 年）。

当然，如果是稀缺的好域名就比较贵了，几百几千万的都有！

你：别说了，俺随便买个便宜的就行……

鱼皮：买了域名还得配 SSL 证书，因为现在做网站都得用 HTTPS 加密传输，不然浏览器会提示 “不安全”，用户看了就跑了。

刚开始可以直接用 Let's Encrypt 提供的免费证书，但只有 3 个月有效期，到期要手动续期，比较麻烦。

想省心的话可以买付费证书，便宜的一年几百块。

你：了解，那我就先用免费的，看来上线也花不了几个钱。

鱼皮：哎，可不能这么说，网站正式上线运营后，花钱的地方可多着呢！尤其是安全防护。

安全防护

做视频网站要面对两大安全威胁。第一个是 内容安全，你总不能让用户随便上传违规视频吧？万一上传了不该传的内容，网站直接就被封了。

你紧张起来：对啊，我人工审核也看不过来啊…… 怎么办？

鱼皮：可以用内容审核服务。视频审核包含画面和声音两部分，比文字审核更贵，审核 1000 小时视频，大概几千块。

你：还有第二个威胁呢？

鱼皮：第二个是最最最难应对的 网络攻击。做视频网站，尤其是有付费内容的，特别容易被攻击。DDoS 流量攻击想把你冲垮、SQL 注入想偷你数据、XSS 攻击想搞你用户、爬虫想盗你视频……

你：这么坏的吗？那我咋防啊！

鱼皮：常用的是 Web 应用防火墙（WAF）和 DDoS 防护服务。Web 防火墙能防 SQL 注入、XSS 攻击这些应用层攻击，而 DDoS 防护能抵御大规模流量冲击。

但是这些商业级服务都挺贵的，可能一年就是几万几十万……

你惊呼：我为了防止被攻击，还要搭这么多钱？！

鱼皮笑了：好消息是，有些云服务商会提供一点点免费的 DDoS 基础防护，还有相对便宜的轻量版 DDoS 防护包。

我的建议是，刚开始就先用免费的，加上代码里做好防 SQL 注入、XSS 这些安全措施，其实够用了。等网站真做起来、有收入了，再花钱买商业级的防护服务就好。

你点了点头：是呀，如果没收入，被攻击就被攻击吧，哼！

鱼皮微笑道：你这心态也不错哈哈。除了刚才说的这些，随着你网站的成熟，还可能会用到很多第三方服务，比如短信验证码、邮件推送、 等等，这些也都是成本。

总成本

讲到这里，你应该已经了解了视频网站的整个技术架构和成本。

最后再总结一下，如果一个人做个小型的视频网站，一年到底要花多少钱？

你看着这个表，倒吸一口凉气：视频网站的成本真高啊……

鱼皮：没错，这还只是保守估计。如果你的网站真火了，每天几万人看视频，一年光流量费就得有几十万吧。

而且刚才说的都只是网站本身的成本，如果你一个人做累了，要组个团队开发呢？

按照一线城市的成本算算，前端开发 + 后端开发 + 测试工程师 + 运维工程师，再加上五险一金，差不多每月要接近 10 万了。

你瞪大眼睛：那一年就是一百万？

鱼皮：没错，人力成本才是最贵的。

你：好了你别说了，我不做了，我不做了！我现在终于理解为什么那些网站都要收费了……

鱼皮：不过说实话，虽然成本不低，但那些网站收费真的太贵了，其实成本远没那么高，更多的是利用人性赚取暴利！

所以比起花钱看那些乱七八糟的网站，把钱和时间投资在学习上，才是最有价值的。

你点了点头：这次一定！再看一期你的教程，我就睡觉啦~

更多

💻 编程学习交流：编程导航 📃 简历快速制作：老鱼简历 ✏️ 面试刷题神器：面试鸭

引言

哈喽大家好，很多时候，我们的游戏项目为了美观和保证风格的统一，都会用到外部字体库。

但是，外部字体库通常是完整的字库，体积非常的大，例如完整的simkai字体库就达到了11.24MB。

要知道，现在的微信小游戏限制主包的大小不能超过4M，即使你把字体放在分包，占去近50%的代码包大小，想想也不太合适。

因此，我们如果想要能够顺利地在游戏中用上漂亮的字体，那我们得想办法将字库瘦下来。

言归正传，本期将带小伙伴们一起来看下，如何将我们想用的字库从11.24M瘦到不到1M 。

本文源工程可在文末获取，小伙伴们自行前往。

精简字库原理

据了解，一个完整的字库估计有3~4万个汉字，但实际上我们游戏项目需要用到的可能只占10%~20%，甚至更少，像其中的一些汉字囧、烎、嫑、勥、忈、巭、怹、颪、氼、兲‌，别说用，笔者连读都不会读。（会读的小伙伴请打在评论区，我给你点赞）

游戏项目中，用到文字的地方通常包含下面几个：

• 1.游戏配置(*.json)，一般配置里面的中文最多。 
• 2.预制体(*.prefab)，有些静态的文字通常就在预制体的Label里。 
• 3.场景(*.scene、*.fire)同上。 
• 4.代码(*.ts)，写死在代码里的。 

因此，要瘦身字体，按照以下2个步骤即可：

• 1.通过工具将上述地方的文字提取出来。
• 2.通过工具从字库中的保留我们提取到的文字，其余的删除。

精简字库实例

1.提取中文字

要提取中文字，我们只需要按照上面的原理，遍历我们的游戏项目中的游戏配置、预制体、场景和代码进行匹配即可。

其中遍历文件，笔者使用的是glob。

匹配中文字的正则表达式是/[\u4e00-\u9fff]/g。

2.精简字库

这里我们使用百度出品的字体子集化工具Fontmin。可以直接通过npm install fontmin进行安装。

工具的使用也非常简单，通过传入原字体、保留的字符和字体输出目录，最后通过fontmin.run这个API生成即可。

3.效果演示

通过node font-minifier.js --project=C:\Users\Administrator\Desktop\demo --source=C:\Users\Administrator\Desktop\simkai.ttf传入工程目录和原字体路径即可。

执行结果可以看到扫描的所有文件。

提取到的所有中文字。

生成的文件及其大小。

精简后的字体大小为802K。

更进一步

除去我们遍历出来的游戏设定的中文字，其实还有一部分中文字我们是不确定的，那就是用户自定义的内容，例如名字和聊天文字。

想要处理这一部分文字，我们只能通过预设，猜到用户会自定义的内容，从而预设保留，可以通过网络上分享的常用内容来完成。

此外工具可以集成到插件或者打包系统里面去，这样后续就不用考虑相关问题，自动生成所需字库即可。

结语

通过上述方法，可以将字库大幅度精简到能够使用的状态，但是也会有一定的瑕疵。

不知道小伙伴们有没有更完美的办法呢？

本文源工程可通过私信发送 fontminifier 获取。

我是"亿元程序员"，一位有着8年游戏行业经验的主程。在游戏开发中，希望能给到您帮助, 也希望通过您能帮助到大家。

AD:笔者线上的小游戏《打螺丝闯关》《贪吃蛇掌机经典》《重力迷宫球》《填色之旅》《方块掌机经典》大家可以自行点击搜索体验。

实不相瞒，想要个赞和爱心！请把该文章分享给你觉得有需要的其他小伙伴。谢谢！

推荐专栏：

知识付费专栏

你知道和不知道的微信小游戏常用API整理，赶紧收藏用起来~

100个Cocos实例

8年主程手把手打造Cocos独立游戏开发框架

和8年游戏主程一起学习设计模式

从零开始开发贪吃蛇小游戏到上线系列

用过 Electron 的兄弟都懂，好处是“会前端就能写桌面”，坏处嘛，三座大山压得喘不过气：

• 体积巨婴
  空项目打出来 100 M+，每次更新又得 80 M，用户宽带不要钱？
• 内存老虎
  开个“Hello World”常驻 300 M，再开几个窗口，直接 1 G 起步，Mac 用户看着彩虹转圈怀疑人生。
• 启动慢动作
  双击图标 → 图标跳 → 白屏 3 秒 → 终于看见界面，节奏堪比 56 K 猫拨号。

老板还天天催：“两周给我 MVP！”—— 抱着 Electron，就像抱着一只会写代码的胖熊猫，可爱但跑不动。

主角登场：GPUI

Rust 圈最近冒出一个“狠角色”——GPUI。

GPUI，是 Zed 编辑器团队推出的 Rust UI 框架，以 GPU 加速和高效渲染模式悄然崛起。

它不卖广告，纯开源，一句话介绍：直接拿显卡画界面，浏览器啥的全部踢出去。

• 底层用 wgpu，Metal / Vulkan / DX12 想调谁就调谁；
• 上层给前端味道的 DSL，写起来像 React，跑起来却是纯原生；
• 安装包 12 M，内存 50 M，启动 0.4 秒，表格滑到 60 帧不带喘。

说人话：把 Electron 的“胖身子”抽真空，留下一身腱子肉。

亮点：为什么值得换坑？

外加 60+现成组件：按钮、表格、树、日历、Markdown、穿梭框……皮肤直接照搬 Web 圈最火的 shadcn/ui，设计师不用改稿，开发直接复制粘贴。

五分钟上手：从零到 Hello Window

① 先装 Rust

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

一路回车即可，30 秒搞定。

② 新建工程

cargo new my-app && cd my-app

③ 把依赖写进 Cargo.toml

[dependencies]

gpui = "0.2"

gpui-component = "0.1"

④ src/main.rs 写几行

use gpui::*;



fn main() {

    App::new().run(|cx: &mut AppContext| {

        Window::new("win", cx)

            .title("我的第一个 GPUI 窗口")

            .build(cx, |cx| {

                Label::new("Hello，GPUI！", cx)

            })

            .unwrap();

    });

}

⑤ 跑！

cargo run

三秒后窗口蹦出来，Hello 世界完成。没有黑框，没有白屏，体验跟原生记事本一样丝滑。

写代码像 React，跑起来像 C++

组件化 + 事件回调，前端同学一看就懂：

Button::new("点我下单", cx)

    .style(ButtonStyle::Primary)

    .on_click(|_, cx| {

        println!("订单已发送");

        notify_user("成交！", cx);

    })

背后是 Rust 的零成本抽象，编译完就是机器码，没有浏览器，没有虚拟机，没有 GC 卡顿，性能直接拉满。

老网页也别扔，一键塞进来

历史项目里还有 React 报表？开 webview 特性就行：

gpui-component = { version = "0.1", features = ["webview"] }

窗口里留一块“浏览器区域”，把旧地址挂进去，零改动复用，妈妈再也不用担心重写代码。

Electron 依然是老大哥，但“胖身子”在 2025 年真的有点跟不上节奏。
新项目、新团队、新想法，不妨给 GPUI 一个机会——试过之后，你可能再也回不去了。

• GPUI 官网：https://www.gpui.rs/
• GPUI Component 官网：https://longbridge.github.io/gpui-component/

略想了一下才发现，自己好像有大半年都没有关注过 TIOBE 社区了。

TIOBE 编程社区相信大家都听过，这是一个查看各种编程语言流行程度和趋势的社区，每个月都有榜单更新，每年也会有年度榜单和总结出炉。

昨晚在家整理浏览器收藏夹时，才想起了 TIOBE 社区，于是打开看了一眼最近的 TIOBE 编程语言社区指数。

没想到，Java 居然已经跌出前三了，并且和第一名 Python 的差距也进一步拉开到了近 18%。

回想起几年前，Java 曾是何等地风光。

各种基于 Java 技术栈所打造的 Web 后端、互联网服务成为了移动互联网时代的中坚力量，同时以 Java 开发为主的后端岗位也是无数求职者们竞相选择的目标。

然而这才过去几年，如今的 Java 似乎也没有了当年那种无与争锋的强劲势头，由此可见 AI 领域的持续进化和繁荣对它的冲击到底有多大。

用数据说话最有说服力。

拉了一下最近这二十多年来 Java 的 TIOBE 社区指数变化趋势看了看，情况似乎不容客观。

可以明显看到的是一个：呈震荡式下降的趋势。

现如今，Java 日常跌出前三已经成为了常态，并且和常居榜首的 Python 的差距也是越拉越大了。

在目前最新发布的 TIOBE Index 榜单中排名前十的编程语言分别是：

• Python
• C++
• C
• Java
• C#
• JavaScript
• Visual Basic
• Go
• Perl
• Delphi/Object Pascal

其中 Python 可谓是一骑绝尘，与排名第二的 C++ 甚至拉开了近 17% 的差距，呈现了断崖式领先的格局。

不愧是 AI 领域当仁不让的“宠儿”，这势头其他编程语言简直是望尘莫及！

另外还值得一提的就是 C 语言。

最近这几个月 C 语言的 TIOBE Index Ratings 比率一直在回升，这说明其生命力还是非常繁荣的，这对于一个已经诞生 50 多年的编程语言来说，着实不易。

C 语言于上个世纪 70 年代初诞生于贝尔实验室，由丹尼斯·里奇（Dennis MacAlistair Ritchie）以肯·汤普森（Kenneth Lane Thompson）所设计的 B 语言为基础改进发展而来的。

就像之前 TIOBE 社区上所描述的，这可能主要和当下物联网（IoT）技术的发展繁荣，以及和当今发布的大量小型智能设备有关。毕竟 C 语言运行于这些对性能有着苛刻要求的小型设备时，性能依然是最出色的。

说到底，编程语言本身并没有所谓的优劣之分，只有合适的应用场景与项目需求。

按照官方的说法，TIOBE 榜单编程语言指数的计算和主流搜索引擎上不同编程语言的搜索命中数是有关的，所以某一程度上来说，可以反映出某个编程语言的热门程度（流行程度、受关注程度）。

而通过观察一个时间跨度范围内的 TIOBE 指数变化，则可以一定程度上看出某个编程语言的发展趋势，这对于学习者来说，可以作为一个参考。

Java：我啥场面没见过

曾经的 Java 可谓是互联网时代不可或缺的存在。早几年的 Java 曲线一直处于高位游走，彼时的 Java 正是构成当下互联网生态繁荣的重要编程语言，无数的 Web 后端、互联网服务，甚至是移动端开发等等都是 Java 的擅长领域。

而如今随着 AI 领域的发展和繁荣，曾经的扛把子如今似乎也感受到了前所未有的压力。

C语言：我厉兵秣马

流水的语言，铁打的 C。

C 语言总是一个经久不衰的经典编程语言，同时也是为数不多总能闯进榜单前三的经典编程语言。

自诞生之日起，C 语言就凭借其灵活性、细粒度和高性能等特性获得了无可替代的位置，就像上文说的，随着如今的万物互联的物联网（IoT）领域的兴起，C 语言地位依然很稳。

C++：我稳中求进

C++ 的确是一门强大的语言，但语言本身的包袱也的确是不小，而且最近这几年的指数趋势稳中求进，加油吧老大哥。

Python：我逆流而上

当别的编程语言都在震荡甚至下跌之时，Python 这几年却强势上扬，这主要和当下的数据科学、机器学习、人工智能等科学领域的繁荣有着很大的关系。

PHP：我现在有点慌

PHP：我不管，我才是世界上最好的编程语言，不接受反驳（手动doge）。

好了，那以上就是今天的内容分享了，感谢大家的阅读，我们下篇见。

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

这两年随着鸿蒙系统相关的争议变多，讨论Flutter 在鸿蒙上的适配的争议也开始变多了。

比如前段时间写了一篇文章讨论用Flutter开发鸿蒙应用。

Flutter 3.35倒逼鸿蒙：兼容or出局，没有第三条路！

就有人评论说应该是Flutter官方适配鸿蒙，而不是鸿蒙适配Flutter。

其实这么说也是有一点道理的（虽然不多），今天老刘就展开分析以下到底应该是谁来适配谁？

从技术角度看：Flutter确实应该主动适配鸿蒙

Flutter作为跨平台框架，它的核心价值就是"一套代码，多端运行"，所以如果不能适配重要平台，那就失去了跨平台的意义。

就像当年Flutter必须适配iOS和Android一样。

这不是谁求谁的问题，这是技术逻辑的问题。

Flutter从诞生那天起，就打着"Write once, run anywhere"的旗号。

但是事实是Flutter官方确实没有表现出适配意愿。

现实情况更复杂：这是一个博弈过程

理想很丰满，现实很骨感。

技术逻辑是一回事，商业逻辑是另一回事。

在当前的经济形势下，各个企业去增加一个独立的鸿蒙团队的成本是难以接受的。

Flutter的价值就在于能够有效的降低这种成本。

因此站在鸿蒙的角度，是应该主动适配Flutter的，而不是等待Flutter官方适配。

其实不仅仅是Flutter，主流的跨平台框架鸿蒙官方都有必要去主动适配。

这就像是一个新开的商场，你不能指望品牌商主动来入驻。

你得主动去招商，提供优惠政策，比如免费装修。

鸿蒙的困境：

• 用户基数还很少，开发者投入意愿不强。
• 生态建设需要时间，短期内难以完全替代Android。
• 政策推动有限，最终还是要靠技术魅力。 

Flutter的考量：

• Google作为Flutter的主导者，对鸿蒙的态度可能比较复杂。

  这个有国际形势的原因，具体背后有哪些权衡咱也不知道，咱也不敢说。

• 本质的原因是鸿蒙的体量还不够。

  就好像当年微软的Windows Phone，技术很好，没有足够的市场份额，开发者就不会买账。

所以从谁受益的角度来看，明显鸿蒙方面去适配Flutter的收益更大。

鸿蒙已经在做Flutter适配

话说回来，其实鸿蒙方面已经在为包括Flutter在内的跨平台框架做适配了。

而且动作还不小。

关键时间线

让我们先看看这几年鸿蒙Flutter适配的关键节点：

2021年1月 - 美团外卖MTFlutter团队率先突破。

发布《让Flutter在鸿蒙系统上跑起来》技术文章。

应该是业界首次公开的Flutter鸿蒙适配探索。

2023年8月 - 华为在HDC大会正式发声。

发布HarmonyOS NEXT，确定第一批跨平台框架适配名单：

• Flutter
• React Native
• 京东Taro
• uni-app

2023年9月 - OpenHarmony-SIG组织正式开源Flutter适配项目。

基于Flutter 3.7版本进行适配。

这意味着适配工作从企业内部走向了开源社区。

2024年8月 - 三方库适配取得重大进展。

深开鸿、开鸿智谷、鸿湖万联完成36个Flutter三方库适配。

其中9个完成测试验收。

具体适配工作有哪些

从技术层面来看，鸿蒙适配Flutter主要需要做这几件事：

嵌入层开发

重新实现Flutter嵌入层以适配鸿蒙平台。

这是最核心的工作，相当于给Flutter换了一个"底盘"。

Flutter Engine移植

基于Android版本进行鸿蒙平台的移植。

这里有个巧妙的地方，鸿蒙系统延用了Android的很多技术方案。

比如Vulkan图形API。

所以把Impeller这样的渲染引擎移植过来，并不需要大动干戈。

开发工具适配

Flutter Tools支持构建HAP包。

这样开发者就可以用熟悉的Flutter命令行工具直接构建鸿蒙应用了。

生态建设的困局

但是，技术适配只是第一步，真正的挑战在于生态建设。

简单来说就是：Flutter有了，但是三方库还没有完全适配好。

从技术原理来说，如果是纯Dart的三方库，适配起来应该比较简单。

大概率是能直接运行的，或者极少的修改就能运行。

但是如果涉及到原生代码的三方库，那就麻烦了。

需要重新移植Android/iOS的原生代码到鸿蒙平台。

这个工作量就比较大了。

而且很多三方库的维护者可能对鸿蒙平台并不熟悉，更没有去适配的意愿。

对鸿蒙上各种开发框架来说都是这样的，基础库的不完善造成了开发者移植app的困难，进一步造成了App数量的缺少，即使移植过来也可能是功能缺失的。

应用数量和质量都不够就很难快速提升用户量，用户量不够就很难吸引足够多的开发者。

这就形成了一个恶性循环。

总结

其实说到底，这也不能说是什么博弈。

任何一个跨平台框架都不可能去适配所有的系统。

就像Flutter也没有适配塞班、Windows Phone这些已经消失的系统一样。

反过来说，作为体量还不够大的系统，主动去提供更好的应用移植解决方案，确实是快速建立生态的最佳路径。

老刘作为一个开发人员，我觉得一个新的系统要想快速建立生态，其实更好的方案是向上提供一套和现有最流行系统（比如Android）兼容的系统级API。

这样大部分应用可以用最小的代价迁移到新系统上。

如果你真的觉得现有的系统API有很大的缺陷，也完全可以在现有API基础上做增量优化。

如果你的优化真的有很大先进性，随着开发者增加，自然有人会使用。

当然这只是开发者的角度。

很多事情也不是给开发者做的。

连API都是全新的全自主研发系统和兼容API的系统，对很多不懂技术的人来说还是有很大差别的。

另一方面，鸿蒙系统这种设计在智能家居、汽车等不太依赖现有生态的场景下，也有自己的优势。

毕竟在这些新兴领域，大家都是从零开始，没有历史包袱。

鸿蒙的分布式架构、万物互联的理念，在这些场景下确实有独特的价值。

所以，与其纠结谁适配谁，不如关注技术本身能解决什么问题。

Flutter适配鸿蒙也好，鸿蒙适配Flutter也好，最终受益的都是开发者和用户。

技术的发展从来不是零和游戏，而是共同进步的过程。

如果看到这里的同学对客户端或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。 私信免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。 可以作为Flutter学习的知识地图。

—— laoliu_dev

你有没有遇到过这样的诡异场景：明明以为 [1,2,3].map(parseInt) 会返回 [1,2,3]，实际运行却得到 [1, NaN, NaN]？

这行看似简单的代码，藏着 JS 数组方法、函数传参、包装类等多个核心知识点的关联。今天我们就从这个经典坑点切入，一步步拆解 map 方法的底层逻辑，顺带理清 NaN、包装类、字符串处理等容易混淆的知识点。

一、先踩坑：为什么 [1,2,3].map (parseInt) 不是 [1,2,3]？

要搞懂这个问题，我们得先明确两个关键：map 方法的参数传递规则，以及 parseInt 的工作原理。

1. map 方法的真正传参逻辑

MDN 明确说明：map 方法会遍历原数组，对每个元素调用回调函数，并将三个参数依次传入回调：

• 当前遍历的元素（item）
• 元素的索引（index）
• 原数组本身（arr）

也就是说，[1,2,3].map(parseInt) 等价于：

javascript

运行

[1,2,3].map((item, index, arr) => {

  return parseInt(item, index, arr);

});

这里的关键是：map 会强制传递三个参数给回调，而不是只传我们以为的 “元素本身”。

2. parseInt 的参数陷阱

parseInt 的语法是 parseInt(string, radix)，它只接收两个有效参数：

• 第一个参数：要转换的字符串（非字符串会先转字符串）
• 第二个参数：基数（进制，范围 2-36，0 或省略则默认 10 进制）
• 第三个参数会被直接忽略

结合 map 的传参，我们逐次分析遍历过程：

• 第一次遍历：item=1，index=0 → parseInt (1, 0)。基数 0 等价于 10 进制，结果 1。
• 第二次遍历：item=2，index=1 → parseInt (2, 1)。基数 1 无效（必须≥2），结果 NaN。
• 第三次遍历：item=3，index=2 → parseInt (3, 2)。2 进制中只有 0 和 1，3 无效，结果 NaN。

这就是为什么最终结果是 [1, NaN, NaN] —— 不是 map 或 parseInt 本身有问题，而是参数传递的 “错位匹配” 导致的。

3. 正确写法是什么？

如果想通过 map 实现 “数组元素转数字”，正确做法是明确回调函数的参数，只给 parseInt 传需要的值：

javascript

运行

// 方法1：手动控制参数

[1,2,3].map(item => parseInt(item)); 

// 方法2：使用Number简化

[1,2,3].map(Number); 

// 两种写法结果都是 [1,2,3]

二、吃透 map 方法：不止是 “遍历 + 返回”

解决了坑点，我们再深入理解 map 的核心特性 —— 它是 ES6 数组新增的纯函数（不改变原数组，返回新数组），这也是它和 forEach 的核心区别。

1. map 的核心规则（必记）

• 不改变原数组：无论回调函数做什么操作，原数组的元素都不会被修改。
• 返回新数组：新数组长度与原数组一致，每个元素是回调函数的返回值。
• 跳过空元素：map 会忽略数组中的 empty 空位（forEach 也会），但不会忽略 undefined 和 null。

示例验证：

javascript

运行

const arr = [1, 2, 3, , 5]; // 第4位是empty

const newArr = arr.map(item => item * 2);

console.log(newArr); // [2,4,6, ,10]（保留空位）

console.log(arr); // [1,2,3, ,5]（原数组不变）

2. 实用场景：从基础到进阶

map 的核心价值是 “数据转换”，日常开发中高频使用：

• 基础转换：数组元素的统一处理（如平方、转格式）

  javascript

  运行

  const arr = [1,2,3,4,5,6];
  
  const squares = arr.map(item => item * item); // [1,4,9,16,25,36]
  
  

• 复杂转换：提取对象数组的特定属性

  javascript

  运行

  const users = [{name: '张三'}, {name: '李四'}, {name: '王五'}];
  
  const names = users.map(user => user.name); // ['张三', '李四', '王五']
  
  

三、延伸知识点：NaN 与包装类，JS 的 “隐式魔法”

在分析 map 和 parseInt 的过程中，我们遇到了 NaN，而 JS 中字符串能调用length方法的特性，又涉及到 “包装类” 的隐式逻辑 —— 这两个知识点是理解 JS “面向对象特性” 的关键。

1. NaN：不是数字的 “数字”

NaN 的全称是 “Not a Number”，但 typeof 检测结果是number，这是它的第一个反直觉点。

什么时候会出现 NaN？

• 无效的数学运算：0/0、Math.sqrt(-1)、"abc"-10
• 类型转换失败：parseInt("hello")、Number(undefined)
• 注意：Infinity（6/0）和-Infinity（-6/0）不是 NaN，它们是有效的 “无穷大” 数值。

如何正确判断 NaN？

因为NaN === NaN的结果是false（NaN 不等于任何值，包括它自己），所以必须用专门的方法：

javascript

运行

// 推荐：ES6新增的Number.isNaN（只检测NaN）

Number.isNaN(parseInt("hello")); // true



// 不推荐：window.isNaN（会先转换类型，误判情况多）

isNaN("hello"); // true（"hello"转数字是NaN）

isNaN(123); // false

2. 包装类：JS 让 “简单类型” 拥有对象能力

JS 是完全面向对象的语言，但我们平时写的"hello".length、520.1314.toFixed(2)，看起来是 “简单数据类型调用对象方法”—— 这背后就是包装类的隐式操作。

包装类的工作流程

当你对字符串、数字、布尔值这些简单类型调用方法时，JS 会自动做三件事：

用代码还原这个过程：

javascript

运行

let str = "hello";

console.log(str.length); // 实际执行过程：

const tempObj = new String(str); // 1. 创建包装对象

console.log(tempObj.length); // 2. 调用方法

tempObj = null; // 3. 销毁对象

关键区别：简单类型 vs 包装对象

javascript

运行

let str1 = "hello"; // 简单类型（string）

let str2 = new String("hello"); // 包装对象（object）



console.log(typeof str1); // "string"

console.log(typeof str2); // "object"

console.log(str1.length === str2.length); // true（方法调用结果一致）

四、拓展：字符串处理的常见误区（length、slice、substring）

包装类让字符串拥有了对象方法，但字符串处理中也有不少容易踩坑的点，结合笔记中的案例总结：

1. length 的 “坑”：emoji 占几个字符？

JS 的字符串用 UTF-16 编码存储，常规字符（如 a、中）占 1 个 16 位单位，emoji 和生僻字占 2 个及以上。length 属性统计的是 “16 位单位个数”，而非视觉上的 “字符个数”：

javascript

运行

console.log('a'.length); // 1（常规字符）

console.log('中'.length); // 1（常规字符）

console.log("𝄞".length); // 2（emoji占2个单位）

console.log("👋".length); // 2（emoji占2个单位）

2. slice vs substring：负数索引与起始位置

两者都用于截取字符串，但处理负数索引和起始位置的逻辑不同：

• 负数索引：slice 支持从后往前截取（-1 是最后一位），substring 会把负数转为 0；
• 起始位置：slice 严格按 “前参为起点，后参为终点”，substring 会自动交换大小值（小的当起点）。

示例对比：

javascript

运行

const str = "hello";

console.log(str.slice(-3, -1)); // "ll"（从后数第3位到第1位）

console.log(str.substring(-3, -1)); // ""（负数转0，0>0无结果）

console.log(str.slice(3, 1)); // ""（3>1无结果）

console.log(str.substring(3, 1)); // "el"（自动交换为1-3）

五、总结：从坑点到体系化知识

回到最初的[1,2,3].map(parseInt)，这个坑的本质是 “对 API 参数传递规则的理解不透彻”。但顺着这个坑，我们串联起了：

• map 方法的参数传递、纯函数特性；
• parseInt 的基数规则、类型转换逻辑；
• NaN 的特性与判断方法；
• 包装类的隐式工作流程；
• 字符串处理的常见误区。

JS 的很多 “诡异现象”，本质都是对底层逻辑的不了解。掌握这些核心知识点后，再遇到类似问题时，就能快速定位根源 —— 这也是我们从 “踩坑” 到 “成长” 的关键。

最后留一个小思考：["10","20","30"].map(parseI