1. Get 请求

1.1 以方法的形参接收参数

1.这种方式一般适用参数比较少的情况

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail")

    public Result<User> getUserDetail(String name,String phone) {

        log.info("name:{}",name);

        log.info("phone:{}",phone);

       return  Result.success(null);

    }

}

2.参数用 @RequestParam 标注，表示这个参数需要必传，否则会报错。

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail")

    public Result<User> getUserDetail(@RequestParam String name,@RequestParam String phone) {

        log.info("name:{}",name);

        log.info("phone:{}",phone);

       return  Result.success(null);

    }

}

1.2 以实体类接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail")

    public Result<User> getUserDetail(User user) {

        log.info("name:{}",user.getName());

        log.info("phone:{}",user.getPhone());

       return  Result.success(null);

    }

}

注：Get 请求以实体类接收参数时，不能用 RequestParam 注解进行标注，因为不支持这样的方式获取参数。

1.3 通过 HttpServletRequest 接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @GetMapping("/detail")

    public Result<User> getUserDetail(HttpServletRequest request) {

        String name = request.getParameter("name");

        String phone = request.getParameter("phone");

        log.info("name:{}",name);

        log.info("phone:{}",phone);

       return  Result.success(null);

    }

}

1.4 通过 @PathVariable 注解接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail/{name}/{phone}")

    public Result<User> getUserDetail(@PathVariable String name,@PathVariable String phone) {

        log.info("name:{}",name);

        log.info("phone:{}",phone);

       return  Result.success(null);

    }

}

1.5 接收数组参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail")

    public Result<User> getUserDetail(String[] names) {

        Arrays.asList(names).forEach(name->{

            System.out.println(name);

        });

       return  Result.success(null);

    }

}

1.6 接收集合参数

springboot 接收集合参数，需要用 RequestParam 注解绑定参数，否则会报错！！

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail")

    public Result<User> getUserDetail(@RequestParam List<String> names) {

        names.forEach(name->{

            System.out.println(name);

        });

       return  Result.success(null);

    }

}

2. Post 请求

2.1 以方法的形参接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @PostMapping("/save")

    public Result<User> getUserDetail(String name,String phone) {

      log.info("name:{}",name);

      log.info("phone:{}",phone);

       return  Result.success(null);

    }

}

注：和 Get 请求一样，如果方法形参用 RequestParam 注解标注，表示这个参数需要必传。

2.2 通过 param 提交参数，以实体类接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @PostMapping("/save")

    public Result<User> getUserDetail(User user) {

      log.info("name:{}",user.getName());

      log.info("phone:{}",user.getPhone());

       return  Result.success(null);

    }

}

注：Post 请求以实体类接收参数时，不能用 RequestParam 注解进行标注，因为不支持这样的方式获取参数。

2.3 通过 HttpServletRequest 接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @PostMapping("/save")

    public Result<User> getUserDetail(HttpServletRequest httpServletRequest) {

      log.info("name:{}",httpServletRequest.getParameter("name"));

      log.info("phone:{}",httpServletRequest.getParameter("phone"));

       return  Result.success(null);

    }

}

2.4 通过 @PathVariable 注解进行接收

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @PostMapping("/save/{name}")

    public Result<User> getUserDetail(@PathVariable String name) {

      log.info("name:{}",name);

       return  Result.success(null);

    }

}

2.5 请求体以 form-data 提交参数，以实体类接收参数

form-data 是表单提交的一种方式，比如常见的登录请求。

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(User user) {

      log.info("name:{}",user.getName());

      log.info("phone:{}",user.getPhone());

       return  Result.success(null);

    }

}

2.6 请求体以 x-www-form-urlencoded 提交参数，以实体类接收参数

x-www-form-urlencoded 也是表单提交的一种方式，只不过提交的参数被进行了编码，并且转换成了键值对。

例如你用form-data 提交的参数：

name: 知否君

age: 22

用 x-www-form-urlencoded 提交的参数：

name=%E5%BC%A0%E4%B8%89&age=22

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(User user) {

      log.info("name:{}",user.getName());

      log.info("phone:{}",user.getPhone());

       return  Result.success(null);

    }

}

2.7 通过 @RequestBody 注解接收参数

注：RequestBody 注解主要用来接收前端传过来的 body 中 json 格式的参数。

2.7.1 接收实体类参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestBody User user) {

      log.info("name:{}",user.getName());

      log.info("phone:{}",user.getPhone());

       return  Result.success(null);

    }

}

2.7.2 接收数组和集合

接收数组

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestBody String[] names) {

        Arrays.asList(names).forEach(name->{

            System.out.println(name);

        });

       return  Result.success(null);

    }

}

接收集合

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestBody List<String> names) {

        names.forEach(name->{

            System.out.println(name);

        });

       return  Result.success(null);

    }

}

2.8 通过 Map 接收参数

1.以 param 方式传参， RequestParam 注解接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestParam Map<String,Object> map) {

        System.out.println(map);

        System.out.println(map.get("name"));

       return  Result.success(null);

    }

}

2.以 body json 格式传参，RequestBody 注解接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestBody Map<String,Object> map) {

        System.out.println(map);

        System.out.println(map.get("name"));

       return  Result.success(null);

    }

}

2.9 RequestBody 接收一个参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestBody String name) {

        System.out.println(name);

       return  Result.success(null);

    }

}

3. Delete 请求

3.1 以 param 方式传参，以方法形参接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @DeleteMapping("/delete")

    public Result<User> getUserDetail(@RequestParam String name) {

        System.out.println(name);

       return  Result.success(null);

    }

}

3.2 以 body json 方式传参，以实体类接收参数

注：需要用 RequestBody 注解，否则接收的参数为 null

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @DeleteMapping("/delete")

    public Result<User> getUserDetail(@RequestBody User user) {

        System.out.println(user);

       return  Result.success(null);

    }

}

3.3 以 body json 方式传参，以 map 接收参数

注：需要用 RequestBody 注解，否则接收的参数为 null

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @DeleteMapping("/delete")

    public Result<User> getUserDetail(@RequestBody Map<String,Object> map) {

        System.out.println(map);

       return  Result.success(null);

    }

}

3.4 PathVariable 接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @DeleteMapping("/delete/{name}")

    public Result<User> getUserDetail(@PathVariable String name) {

        System.out.println(name);

       return  Result.success(null);

    }

}

大家好，我是拭心。

最近看到一个很可惜的事：有个阿姨在深圳缴纳了 12 年社保，第 13 年家里突然有事不得不回老家，回去后没再缴纳社保，结果退休后无法领退休工资，还得出来打工赚钱。

之所以这样，是因为阿姨及其家人对退休的相关知识了解不多，痛失一笔收入。

吸取教训，作为在上海工作多年的打工人，为了老有所依，我花了些时间学习了养老金相基本知识，并且估算了一下退休后每月能拿到的钱，这篇文章来聊聊。

文章主要内容：

如何能在上海领退休工资

上海作为全国 GDP 第一的城市，居民的收入也是很可观的。平均工资在 2023 年达到了 12183，平均退休工资在全国也位列前茅：

从上图可以看到，上海的平均退休工资居然有五千多！不用早起不用挤地铁，躺在家里每月就能领五千多，花不完，根本花不完啊！

那么问题来了，我们如何能领到上海的退休工资？

主要有 2 个条件：

第二点很关键：在上海需要缴满社保 10 年，上海 + 其他地方累计需要缴满 15 年。 比如小张在上海工作并缴纳社保满 10 年，然后去青岛缴纳 5 年，最后可以在上海领退休工资；但如果在青岛缴纳了 10 年，在上海缴纳了 5 年，就无法在上海领退休工资了。

需要强调的是，这里说的是「累计缴满」，即使中间有断开也没关系。

还有一个细节是，发工资不等于缴纳社保，个别不正规公司会漏缴社保，这需要我们打工人自己多关注。 身边有朋友遇到过：刚毕业加入的公司规模很小，人力资源不靠谱，干了半年多只缴纳了两个月社保。

怎么看公司有没有给自己缴社保呢？我们可以从随申办上查询：

OK，这就是在上海领退休工资的条件。

退休后大概能领多少钱

掐指一算，社保缴满 15 年的任务我已经完成了一半，但还有二十九年才能领钱，心里苦啊😭。

虽然拿不到，但我对能领多少钱还是非常好奇的，究竟比平均退休工资高还是被平均？🤔

经过一番搜索，我终于发现了退休工资的计算方法。

在国家社会保险公共服务平台网站中，有一个「企业职工养老保险待遇测算」的功能：

国家社会保险公共服务平台 -> 养老保险 -> 企业职工养老保险待遇测算

链接：si.12333.gov.cn/157569.jhtm…

我们只需要输入年龄、预计退休年龄、当前缴纳年限、目前及之前平均工资、养老保险个人账户余额及未来大概工资即可测算退休工资。

如果不知道你的「养老保险个人账户余额」有多少，可以从随申办 app 搜索「养老金」查询余额：

在填完所有需要的信息后，我的预算结果是这样的：

我的天，个十百千万，居然有两万五？这还花的完？？

几秒后冷静下来，我才发现算错了。。。

两万五应该是这样算的：按照当前收入，再连续缴纳 29 年。 😂

对于我们程序员，保持收入 29 年基本是不可能的，我还是重新调整参数再看看吧。

我现在社保缴纳了七年半，如果缴够 15 年社保，退休后我能领多少钱呢？

答案是一万四！看着还不错哈，每天能有 480 元左右，就是不知道 30 年后的物价怎么样了😂。

如果再悲观一点，社保缴纳到 35 岁（然后最低标准缴够 15 年），退休后大概能领多少呢？

答案是一万元！

看了下人民币的贬值率，30 年后的一万元不知道有没有今天三千块钱的购买力😷。

OK，这就是我退休后大概能领到的工资范围。

退休工资的组成

从上面的预算结果中我们可以看到，养老金由三部分组成：基础养老金、个人账户养老金和过渡性养老金，它们都是什么意思呢？

1.基础养老金 = 退休时平均工资 ×（1+平均缴费指数）÷ 2 × 累计缴费年限 × 1%。

退休时平均工资指的是退休时所在地区上年度的社会平均工资。也就是说经济发达地区的基础养老保险金，要高于欠发达地区。

平均缴费指数指的参保人选择的缴纳比例（一般在0.6-3之间）。每个月社保的缴费比例越高，相应的基础养老金越高。

例如，小张退休时，上年度的社会平均工资是 12000。虎虎的缴费指数平均值是 1，累计缴存了15年，他的基础养老金约为：12000*(1+1)/2 * 15 * 1% = 1800。

2.个人账户养老金 = 养老保险个人账户累计金额 ÷ 养老金计发月数。

我们缴纳社保时，一部分会进入个人社保账户，一部分会进入国家统筹账户。个人账户的部分，直接影响退休养老金的计算。

计发月数和我们退休的年龄有直接的关系，退休的越晚，计发月数越少；退休的时间越早，计发月数越多。一般来说，按照 60岁 退休，计发月数是 139 个月。

退休金的计发月数只是用来计算退休金，而不是说只能领这么久的退休金。

例如，小张社保的个人缴纳比例为 8%，社保的计算基数是 9339，他选择在 60 岁退休，那他的个人账户养老金约为：9339 * 8% * 12 * 15 / 139 = 967.49。

3.过渡性养老金 = 退休时平均工资 × 建立个人账户前的缴费年限 × 1.3% × 平均缴费指数

过渡性养老金，是指在养老保险制度发生变化（比如缴费标准提高、计算方法改变、退休年龄调整）的时候，给予受影响群体的资金补充。

这个奖金的计算规则说法不一，一种比较广泛的计算方法是：退休时所在地区的平均工资 x 缴费指数 x 缴费年限 x 过渡系数，其中过渡系数大概在 1% 到 1.4% 之间。

OK，这就是养老金三部分组成的含义。

总结

好了，这篇文章到这里就结束了，主要讲了：

通过写这篇文章，我对养老金的认识更多了一些，希望国家繁荣昌盛，让我退休的时候能多领点钱!

下面看一下改版后的滑块验证码：

我在文章的评论区看到了一些关于这次升级或相关的讨论：

本文将继续破解这次升级后的滑块验证码，看看这次升级对破解的难度有多大影响，如果你还没有了解过如何破解滑块验证码，请先看我之前的文章。

iframe

这次升级，整个滑块都掉用的是外部链接，使用 iframe 呈现，那么在 puppeteer 中如何处理呢？

await page.waitForSelector('iframe');

const elementHandle = await page.$('iframe');

const frame = await elementHandle.contentFrame();

实际上，我们只需要等待 iframe 加载完成，然后获取 iframe 的内容即可。

Frame 对象和 Page 对象有很多相似的方法，比如 frame.$、frame.evaluate 等，我们可以直接使用这些方法来操作 iframe 中的元素。

验证码的识别

上一篇文章采用比较简单的判断方式，当时缺口处有明显的白边，所以只需要找到这个白边即可。

但是本次升级后，缺口不再是白边，而是阴影的效果，并且缺口的形状也不再是拼图，大概率都是曲线的边，所以再判断缺口的方式就不再适用了。

现在我们可以采用一种新的方式，通过对比滑块图片和缺口区域的像素值相似程度来判断缺口位置。

首先还是二值化处理，将图片转换为黑白两色：

可以看到左侧缺口和右侧缺口非常相似，只是做了一点旋转作为干扰。

再看一下，iframe 中还有一个很重要的东西，就是校验的图片：

它是一个 png 图片，所以我们可以把它也转换成二值化，简单的方式就是将透明色转换为白色，非透明色转换为黑色，如果想提高识别精度，可以与背景图一样，通过灰度、二值化的转换方式。

// 获取缺口图像

const captchaVerifyImage = document.querySelector(

  '#captcha-verify_img_slide',

) as HTMLImageElement;

// 创建一个画布，将 image 转换成canvas

const captchaCanvas = document.createElement('canvas');

captchaCanvas.width = captchaVerifyImage.width;

captchaCanvas.height = captchaVerifyImage.height;

const captchaCtx = captchaCanvas.getContext('2d');

captchaCtx.drawImage(

  captchaVerifyImage,

  0,

  0,

  captchaVerifyImage.width,

  captchaVerifyImage.height,

);

const captchaImageData = captchaCtx.getImageData(

  0,

  0,

  captchaVerifyImage.width,

  captchaVerifyImage.height,

);

// 将像素数据转换为二维数组，同样处理灰度、二值化，将像素点转换为0（黑色）或1（白色）

const captchaData: number[][] = [];

for (let h = 0; h < captchaVerifyImage.height; h++) {

  captchaData.push([]);

  for (let w = 0; w < captchaVerifyImage.width; w++) {

    const index = (h * captchaVerifyImage.width + w) * 4;

    const r = captchaImageData.data[index] * 0.2126;

    const g = captchaImageData.data[index + 1] * 0.7152;

    const b = captchaImageData.data[index + 2] * 0.0722;

    if (r + g + b > 30) {

      captchaData[h].push(0);

    } else {

      captchaData[h].push(1);

    }

  }

}

为了对比图形的相似度，二值化后的数据我们页采用二维数组的方式存储，这样可以方便的对比两个图形的相似度。

如果想观测二值化后的真是效果，可以把二位数组转换为颜色，并覆盖到原图上：

// 通过 captchaData 0 黑色 或 1 白色 的值，绘制到 canvas 上，查看效果

for (let h = 0; h < captchaVerifyImage.height; h++) {

  for (let w = 0; w < captchaVerifyImage.width; w++) {

    captchaCtx.fillStyle =

      captchaData[h][w] == 1 ? 'rgba(0,0,0,0)' : 'black';

    captchaCtx.fillRect(w, h, 1, 1);

  }

}

captchaVerifyImage.src = captchaCanvas.toDataURL();

数据拿到后，我们可以开始对比两个图形的相似度，这里就采用非常简单的对比方式，从左向右，逐个像素点对比，横向每个图形的像素一致的点数量纪录下来，然后取最大值，这个最大值就是缺口的位置。

这里我们先优化一下要对比的数据，我们只需要对比缺口的顶部到底部这段的数据，截取这一段，可以减少对比的性能消耗。

// 获取captchaVerifyImage 相对于 .verify-image 的偏移量

const captchaVerifyImageBox = captchaVerifyImage.getBoundingClientRect();

const captchaVerifyImageTop = captchaVerifyImageBox.top;

// 获取缺口图像的位置

const imageBox = image.getBoundingClientRect();

const imageTop = imageBox.top;

// 计算缺口图像的位置，top 向上取整，bottom 向下取整

const top = Math.floor(captchaVerifyImageTop - imageTop);

// data 截取从 top 列到 top + image.height 列的数据

const sliceData = data.slice(top, top + image.height);

然后循环对比两个图形的像素点，计算相似度：

// 循环对比 captchaData 和 sliceData，从左到右，每次增加一列，返回校验相同的数量

const equalPoints = [];

// 从左到右，每次增加一列

for (let leftIndex = 0; leftIndex < sliceData[0].length; leftIndex++) {

  let equalPoint = 0;

  // 新数组 sliceData 截取 leftIndex - leftIndex + captchaVerifyImage.width 列的数据

  const compareSliceData = sliceData.map((item) =>

    item.slice(leftIndex, leftIndex + captchaVerifyImage.width),

  );

  // 循环判断 captchaData 和 compareSliceData 相同值的数量

  for (let h = 0; h < captchaData.length; h++) {

    for (let w = 0; w < captchaData[h].length; w++) {

      if (captchaData[h][w] === compareSliceData[h][w]) {

        equalPoint++;

      }

    }

  }

  equalPoints.push(equalPoint);

}

// 找到最大的相同数量，大概率为缺口位置

return equalPoints.indexOf(Math.max(...equalPoints));

对比时像素较多，不容易直接看到效果，这里写一个简单的二位数组对比，方便各位理解：

[

  [0, 1, 0],

  [1, 0, 1],

  [0, 1, 0],

]

[

  [0, 0, 0, 1, 0, 0],

  [0, 0, 1, 0, 1, 0],

  [0, 0, 0, 1, 0, 0],

]

循环对比，那么第3列开始，匹配的数量可以达到9，所以返回 3，这样就是滑块要移动的位置。

干扰缺口其实对我们这个识别方式没什么影响，最多可能会增加一些失败的概率，我个人测试了一下，识别成功率有 95% 左右。

总结

这次升级后，掘金的滑块验证码的安全性有了一定的提升，还是可以继续破解的，只是难度有所增加。最后再奉劝大家不要滥用这个技能，这只是为了学习和研究，不要用于非法用途。如果各位蹲局子，可不关我事啊。 🤔️

入坑 Jenkins

作为一个前端，想必大家都会有这个想法：“Jenkins 会用就行了，有啥好学的”。

我一直都是这么想的，不就会点个开始构建就行了嘛！

可是碰巧我们之前负责 Jenkins 的前端同事升了职，碰巧这个项目组就剩了两个人，碰巧我比较闲，于是这个“活”就落在我的头上了。

压力一下就上来了，一点不懂 Jenkins 可咋整？

然而现实是没有一点儿压力。

刚开始的时候挺轻松，也就是要发版的流程到我这了，我直接在对应项目上点击开始构建，so easy！可是某一天，突然遇到一个 bug：我们每次 web 端项目发完后，桌面端的 hybrid 包需要我手动改 OSS 上配置文件的版本号，正巧那天忘记更新版本号了，导致桌面端应用本地的 hybrid 没有更新。。。

领导：你要不就别手动更新了，弄成自动化的

我：😨 啊！什么，我我我不会，是不可能的

小弟我之前没有接触过 Jenkins，看着那一堆配置着实有点费脑，于是就只能边百度学习边输出，从 Jenkins 安装开始到配置不同类型的构建流程，踩过不少坑，最后形成这篇文章。如果有能帮到大家的点，我就很开心了，毕竟我也是刚接触的！

说说我经历过的前端部署流程

按照我的经历，我把前端部署流程分为了以下几个阶段：即原始时代 -> 脚本化时代 -> CI/CD 时代。

原始时代

最开始的公司运维是一个小老头，他只负责管理服务器资源，不管各种项目打包之类的。我们就只能自己打包，再手动把构建的文件丢到服务器上。

整体流程就是：本地合并代码 --> 本地打包 --> 上传服务器；

上传服务器可以分为这几个小步骤：打开 xshell --> 连接服务器 --> 进入 tomcat 目录 --> 通过 ftp 上传本地文件。

可能全套下来需要 5 分钟左右。

脚本化时代

为了简化，我写了一个 node 脚本，通过ssh2-sftp-client将上传服务器这一步骤脚本化：

const chalk = require('chalk')

const path = require('path')

const fs = require('fs')

const Client = require('ssh2-sftp-client')

const sftp = new Client()

const envConfig = require('./env.config')



const defalutConfig = {

  port: '22',

  username: 'root',

  password: '123',

  localStatic: './dist.tar.gz',

}



const config = {

  ...defalutConfig,

  host: envConfig.host,

  remoteStatic: envConfig.remoteStatic,

}



const error = chalk.bold.red

const success = chalk.bold.green

function upload(config, options) {

  if (!fs.existsSync('./dist') && !fs.existsSync(options.localStatic)) {

    return

  }

  // 标志上传dist目录

  let isDist = false

  sftp

    .connect(config)

    .then(() => {

      // 判断gz文件存在时 上传gz 不存在时上传dist

      if (fs.existsSync(options.localStatic)) {

        return sftp.put(options.localStatic, options.remoteStatic)

      } else if (fs.existsSync('./dist')) {

        isDist = true

        return sftp.uploadDir('./dist', options.remoteStatic.slice(0, -12))

      }

    })

    .then(() => {

      sftp.end()

      if (!isDist) {

        const { Client } = require('ssh2')

        const conn = new Client()

        conn

          .on('ready', () => {

            // 远程解压

            const remoteModule = options.remoteStatic.replace('dist.tar.gz', '')

            conn.exec(

              `cd ${remoteModule};tar xvf dist.tar.gz`,

              (err, stream) => {

                if (err) throw err

                stream

                  .on('close', (code) => {

                    code === 0

                    conn.end()

                    // 解压完成 删除本地文件

                    fs.unlink(options.localStatic, (err) => {

                      if (err) throw err

                    })

                  })

                  .on('data', (data) => {})

              }

            )

          })

          .connect(config)

      }

    })

    .catch((err) => {

      sftp.end()

    })

}



// 上传文件

upload(config, {

  localStatic: path.resolve(__dirname, config.localStatic), // 本地文件夹路径

  remoteStatic: config.remoteStatic, // 服务器文件夹路径器

})

最后只要通过执行yarn deploy即可实现打包并上传，用了一段时间，队友也都觉得挺好用的，毕竟少了很多手动操作，效率大大提升。

CI/CD 时代

不过用了没多久后，来了个新的运维小年轻，一上来就整了个 Jenkins ，取代了我们手动打包的过程，只要我们点击部署就可以了，当时就感觉 Jenkins 挺方便的，但又觉得和前端没多大关系，也就没学习。

不过也挺烦 Jenkins 的，为啥呢？

当时和测试说的最多的就是“我在我这试试.....我这没问题啊，你刷新一下”，趁这个时候，赶紧打包重新部署下。有了 Jenkins 后，打包都有记录了，测试一看就知道我在哄她了 🙄

Jenkins 解决了什么问题

我觉得在了解一个新事物前，应该先了解下它的出现解决了什么问题。

以我的亲身经历来看，Jenkins 的出现使得 拉取代码 -> 打包 -> 部署 -> 完成后工作（通知、归档、上传CDN等）这一繁琐的流程不需要人为再去干预，一键触发 🛫。

只需要点击开始构建即可，如何你觉得还得每次打开 jenkins 页面去点击构建，可以通过设置代码提交到 master 或合并代码时触发构建，这样就不用每次手动去点击构建了，省时更省力 🚴🏻‍♂️。

Jenkins 部署

Jenkins 中文帮助文档

Jenkins 提供了多种安装方式，我的服务器是 Centos，按照官方教程进行部署即可。

官方提供两种方式进行安装：

方式一：

sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo

sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key



yum install jenkins

方式二：

直接下载 rpm 包进行安装，地址：mirrors.jenkins-ci.org/redhat/

wget https://pkg.jenkins.io/redhat/jenkins-2.449-1.1.noarch.rpm

rpm -ivh jenkins-2.449-1.1.noarch.rpm

安装过程

我是使用方式二进行安装的，来看下具体过程。

首先需要安装 jdk17 以上的版本

接着安装 Jenkins，需要注意：Jenkins 一定要安装最新版本，因为插件要求最新版本，最新的 2.449。

你以为就这么简单？肯定会报错的，通过百度报错信息，报错原因是：Java 环境不对，百度到的解决方法：

修改/etc/init.d/jenkins文件，添加 JDK，但是目录下并没有这个文件，继续百度得知：

使用 systemctl 启动 jenkins 时，不会使用 etc/init.d/jenkins 配置文件，而是使用 /usr/lib/systemd/system/jenkins.service文件。

于是修改：

vim /usr/lib/systemd/system/jenkins.service

搜索 Java，找到上面这一行，打开注释，修改为对应的 JDK 位置：

Environment="JAVA_HOME=/usr/lib/jvm/jdk-17.0.10"

重新启动 Jenkins：

systemctl restart jenkins

查看启动状态，出现如下则说明 Jenkins 启动完成：

接着在浏览器通过 ip:8090 访问，出现如下页面，说明安装成功。

此时需要填写管理员密码，通过 cat /var/lib/jenkins/secrets/initialAdminPassword 即可获取。

Jenkins 配置

出现上述界面，填写密码成功后等待数秒，即可出现如下界面：

选择 安装推荐的插件

这个过程稍微有点慢，可以整理整理文档，等待安装完成。

安装完成后，会出现此页面，需要创建一个管理员用户。

点击开始使用 Jenkins，即可进入 Jenkins 首页。

至此，Jenkins 安装完成 🎉🎉🎉。

安装过程遇到的问题

如何卸载 Jenkins

安装过程遇到了不少坑，基本都是卸载了重新安装，于是就总结了以下卸载的命令。

# 查找是否存在 Jenkins 安装包

rpm -ql jenkins

# 卸载 Jenkins

rpm -e jenkins

# 再次查看 此时会提示：未安装软件包 jenkins

rpm -ql jenkins

# 删除所有 Jenkins 相关目录

find / -iname jenkins | xargs -n 1000 rm -rf

Jenkins 版本更新

Jenkins 发布版本很频繁，基本为一周一次，参考 Jenkins 更新

项目创建

点击 + 新建Item，输入名称，选择类型：

有多种类型可供选择，这里我们主要讲这两种：Freestyle project 和 Pipeline。

Freestyle project

选择这种类型后，就可以通过各种 web 表单（基础信息、源码、构建步骤等），配置完整的构建步骤，对于新手来说，易上手且容易理解，如果第一次接触，创建项目就选择 Freestyle project 即可。

总共有以下几个环节需要配置：

• General


• 源码管理


• 构建触发器


• 构建环境


• Build Steps


• 构建后操作

此时我们点击 OK，创建完如下所示都是空白的，也可以通过创建时的复制选项，复制之前项目的配置：

接着就如同填写表单信息，一步步完成构建工作。

General

项目基本信息也就是对所打包项目的描述信息：

比如描述这里，可以写项目名称、描述、输出环境等等。

Discard old builds 丢弃旧的构建

可以理解为清初构建历史，Jenkins 每打包一次就会产生一个构建历史记录，在构建历史中可以看到从第一次到最新的构建信息，这会导致磁盘空间消耗。

点击配置名称或勾选，会自动展开配置项。这里我们可以设置保持构建的最大个数为5，则当前项目的构建历史记录只会保留最新的 5 个，并自动删除掉最老的构建。

这个可以按照自己的需求来设置，比如保留 7 天的构建记录或保留最多 100 个构建记录。

Jenkins 的大多数配置都有 高级 选项，在高级选项中可以做更详细的配置。

This project is parameterized

可以理解为此构建后续过程可能用到的参数，可以是手动输入或选项等，如：git 分支、构建环境、特定的配置等等。通过这种方式，项目可以更加灵活和可配置，以适应不同的构建需求和环境。

默认有 8 种参数类型：

Git Parameter 需要在 系统管理 -> 插件管理 搜索 Git Parameter 插件进行安装，安装完成后重启才会有这个参数。

通过 添加参数 来设置后续会用到的参数，比如设置名称为 delopyTag 的 Git Parameter 参数来指定要构建的分支，设置名称为 DEPLOYPATH 的 Choice Parameter 参数来指定部署环境等等。

源码管理

Repositories

一般公司项目都是从 gitlab 上拉代码，首先设置 Repository URL，填写 git 仓库地址，比如：https://gitlab.com/xxx/xxx.git

填写完后会报错如下：

可以通过添加 Credentials 凭证解决，在 Jenkins 中，Git 的 Credentials 是用于访问 Git 仓库的认证信息，这些凭据可以是用户名和密码、SSH 密钥或其他认证机制，以确保 Jenkins 能够安全的与 Git 仓库进行交互，即构建过程中自动拉取代码、执行构建任务等。

方式一：在当前页面填写帐号、密码

选择添加 -> Jenkins -> 填写 git 用户名、密码等信息生成一个新的 Credentials，然后重新选择我们刚刚添加的 Credentials，报错信息自动消失

这样添加会有一个问题，就是如果有多个项目时，每次都需要手动填写 Git 账户和密码信息。

方式二：Jenkins 全局凭证设置

在 Global Credentials 中设置全局的凭证。

然后在项目中配置时可以直接选择我们刚刚添加的 Credentials，报错信息自动消失。

Branches to build

这里构建的分支，可以设置为我们上面设置的 delopyTag 参数，即用户自己选择的分支进行构建。

构建触发器

特定情况下出发构建，如定时触发、代码提交或合并时触发、其他任务完成时触发等。

如果没有特殊的要求时，这一步完全可以不用设置，在需要构建时我们只需要手动点击开始构建即可。

构建环境

构建环境是在构建开始之前的准备工作，如清除上次构建、指定构建工具、设置 JDK 、Node 版本、生成版本号等。

Provide Node & npm bin/folder to PATH

默认是没有这一项的，但前端部署需要 Node 环境支持，所以需要在 系统管理 -> 插件管理 搜索 nodejs 插件进行安装，安装完成后重启才会展示这项配置。

但此时还是不能选择的，需要在 系统管理 -> 全局工具配置 中先安装 NodeJs，根据不同环境配置，可同时安装多个 NodeJs 版本。

之后在 Provide Node 处才有可供选择的 Node 环境。

Create a formatted version number

这个就是我用来解决了一开始问题的配置项，也就是把每次打包的结果上传到 OSS 服务器上时生成一个新的版本号，在 Electron 项目中通过对比版本号，自动更新对应的 hybrid 包，领导都爱上我了 😜。

首先需要安装插件 Version Number Plugin，在 系统管理 -> 插件管理 中搜索安装，然后重启 Jenkins 即可

如果想要重置版本号，只要设置Number of builds since the start of the project为 0 即可，此时就会从 1.7.0 重新开始。

Build Steps

这是最为重要的环节，主要用于定义整个构建过程的具体任务和操作，包括执行脚本、编译代码、打包应用等。

我们可以通过 Shell 脚本来完成前端项目常见的操作：安装依赖、打包、压缩、上传到 OSS 等。

点击 增加构建步骤 -> Execute shell，在上方输入 shell 脚本，常见的如下：

#环境变量

echo $PATH

#node版本号

node -v

#npm版本号

npm -v





#进入jenkins workspace的项目目录

echo ${WORKSPACE}

cd ${WORKSPACE}



#下载依赖包

yarn

#开始打包

yarn run build



#进入到打包目录

cd dist

#删除上次打包生成的压缩文件

rm -rf *.tar.gz



#上传oss，如果没有需要可删除此段代码

ossurl="xxx"

curl "xxx" > RELEASES.json

node deploy-oss.cjs -- accessKeyId=$OSS_KEY accessKeySecret=$OSS_SECRET zipDir=tmp.zip ossUrl=xxx/v${BUILD_VERSION}.zip

node deploy-oss.cjs -- accessKeyId=$OSS_KEY accessKeySecret=$OSS_SECRET zipDir=RELEASES.json ossUrl=xxx/RELEASES.json



#把生成的项目打包成压缩包方便传输到远程服务器

tar -zcvf `date +%Y%m%d%H%M%S`.tar.gz *

#回到上层工作目录

cd ../

构建后操作

通过上面的构建步骤，我们已经完成了项目的打包，此时我们需要执行一些后续操作，如部署应用、发送通知、触发其他 Job等操作。

Send build artifacts over SSH

通过 Send build artifacts over SSH，我们可以将构建好的产物（一般是压缩后的文件）通过 ssh 发送到指定的服务器上用于部署，比如 Jenkins 服务器是 10.10，需要将压缩文件发送到 10.11 服务器进行部署，需要以下步骤：

Transfer Set 参数配置

• Source files：需要传输的文件，也就是通过上一步 Build Steps 后生成的压缩文件，这个路径是相对于“工作空间”的路径，即只需要输入 dist/*.tar.gz 即可


• Remove prefix：删除传输文件指定的前缀，如 Source files 设置为dist/*.tar.gz ，此时设置 Remove prefix 为/dist，移除前缀，只传输 *.tar.gz 文件；如果不设置酒会传输 dist/*.tar.gz 包含了 dist 整个目录，并且会自动在上传后的服务器中创建 /dist 这个路径。如果只需要传输压缩包，则移除前缀即可


• Remote directory：文件传输到远程服务器上的具体目录，会与 Publish over SSH 插件系统配置中的 Remote directory 进行拼接，如我们之前设置的目录是 /home/jenkins，此处在写入 qmp_pc_ddm，那么最终上传的路径为 /home/jenkins/qmp_pc_ddm，与之前不同的是，如果此路径不存在时会自动创建，这样设置后，Jenkins 服务器构建后的产物会通过 ssh 上传到此目录，供下一步使用。


• Exec command
  
  

  文件传输完成后执行自定义 Shell 脚本，比如移动文件到指定目录、解压文件、启动服务等。

  
  

  #!/bin/bash
  
  
  
  #进入远程服务器的目录
  
  project_dir=/usr/local/nginx/qmp_pc_ddm/${DEPLOYPATH}
  
  cd $project_dir
  
  
  
  #移动压缩包
  
  sudo mv /home/jenkins/qmp_pc_ddm/*.tar.gz  .
  
  
  
  #找到新的压缩包
  
  new_dist=`ls -ltr *.tar.gz | awk '{print $NF}' |tail -1`
  
  echo $new_dist
  
  
  
  #解压缩
  
  sudo tar -zxvf $new_dist
  
  
  
  #删除压缩包
  
  sudo rm *.tar.gz
  
  

  
  

  这一步可以使用之前定义的参数，如 ${DEPLOYPATH}，以及 Jenkins 提供的变量：如 ${WORKSPACE} 来引用 Jenkins 的工作空间路径等。

Build other projects

添加 Build other projects，在项目构建成功后，触发相关联的应用开始打包。

另外还可以配置企业微信通知、生成构建报告等工作。

此时，所有的配置都设置完成，我们点击保存配置，返回到构建页。

构建

点击 Build with parameters 选择对应的分支和部署环境，点击开始构建

在控制台输出中，可以看到打包的详细过程，

可以看到我们在Build Steps中执行的 Shell 脚本的输出如下：

以及我们通过 Publish Over SSH 插件将构建产物传输的指定服务器的输出：

最终需要部署的服务器就有了以下文件：

Pipeline

对于简单的构建需求或新手用户来说，我们可以直接选择 FreeStyle project。而对于复杂的构建流程或需要更高灵活性和扩展性的场景来说，Pipeline 则更具优势。

通过 新建任务 -> 流水线 创建一个流水线项目。

开始配置前请先阅读下流水线章节。

生成方式

首先，Jenkins 流水线是一套插件，在最开始的插件推荐安装时会自动安装，如果选择自定义安装时，需要手动安装这一套插件。

Jenkins 流水线的定义有两种方式：Pipeline script 和 Pipeline script from SCM。

Pipeline script

Pipeline script 是直接在 Jenkins 页面的配置中写脚本，可直接定义和执行，比较直观。

Pipeline script from SCM

Pipeline script from SCM 是将脚本文件和项目代码放在一起，即 Jenkinsfile，也可自定义名称。

当 Jenkins 执行构建任务时，会从 git 中拉取该仓库到本地，然后读取 Jenkinsfile 的内容执行相应步骤，通常认为在 Jenkinsfile 中定义并检查源代码控制是最佳实践。

当选择 Pipeline script from SCM 后，需要设置 SCM 为 git，告诉 Jenkins 从指定的 Git 仓库中拉取包含 Pipeline 脚本的文件。

如果没有对应的文件时，任务会失败并发出报错信息。

重要概念

了解完上面的基础配置，我们先找一段示例代码，粘贴在项目的配置中：

pipeline {

  agent any

    stages {

      stage('Build') {

        steps {

          echo 'Build'

        }

      }

      stage('Test') {

        steps {

          echo 'Test'

        }

      }

      stage('Deploy') {

        steps {

          echo 'Deploy'

      }

    }

  }

}

看下它的输出结果：

接着看一下上面语法中几个重要的概念。

流水线 pipline

定义了整个项目的构建过程, 包括：构建、测试和交付应用程序的阶段。

流水线顶层必须是一个 block，pipeline{}，作为整个流水线的根节点，如下：

pipeline {

  /* insert Declarative Pipeline here */

}

节点 agent

agent 用来指定在哪个代理节点上执行构建，即执行流水线，可以设置为 any，表示 Jenkins 可以在任何可用的代理节点上执行构建任务。

但一般在实际项目中，为了满足更复杂的构建需求，提高构建效率和资源利用率，以及确保构建环境的一致性，会根据项目的具体需求和资源情况，设置不同的代理节点来执行流水线。

如：

pipeline {

  agent {

        node {

            label 'slave_2_34'

        }

    }

    ...

}

可以通过 系统管理 -> 节点列表 增加节点，可以看到默认有一个 master 节点，主要负责协调和管理整个 Jenkins 系统的运行，包括任务的调度、代理节点的管理、插件的安装和配置等。

阶段 stage

定义流水线的执行过程，如：Build、Test 和 Deploy，可以在可视化的查看目前的状态/进展。

注意：参数可以传入任何内容。不一定非得 Build、Test，也可以传入 打包、测试，与红框内的几个阶段名对应。

步骤 steps

执行某阶段具体的步骤。

语法

了解上述概念后，我们仅仅只能看懂一个 Pipeline script 脚本，但距离真正的动手写还有点距离，此时就需要来了解下流水线语法。

我将上面通过 Freestyle project 的脚本翻译成 Pipeline script 的语法：

pipeline {

    agent any

    triggers {

        gitlab(triggerOnPush: true, triggerOnMergeRequest: true, branchFilterType: 'All')

    }

    parameters {

     gitParameter branchFilter: 'origin/(.*)', defaultValue: 'master', name: 'delopyTag', type: 'PT_BRANCH'

    }

    stages {

        stage('拉取代码') {

          steps {

            git branch: "${params.delopyTag}", credentialsId: 'xxx', url: 'https://xxx/fe/qmp_doc_hy.git'

          }

        }

        stage('安装依赖') {

          steps {

            nodejs('node-v16.20.2') {

              sh '''

                #!/bin/bash

                source /etc/profile

                echo "下载安装包"

                yarn config set registry https://registry.npmmirror.com

                yarn

              '''

            }

            sleep 5

          }

        }

        stage('编译') {

          steps {

            sh '''

              #!/bin/bash

              source /etc/profile

              yarn run build

              sleep 5

              if [ -d dist ];then

                cd dist

                rm -rf *.tar.gz



                tar -zcvf `date +%Y%m%d%H%M%S`.tar.gz *

              fi

            '''

            sleep 5

          }

        }

        stage('解压') {

          steps {

            echo '解压'

            sshPublisher(

                publishers: [

                    sshPublisherDesc(

                        configName: 'server(101.201.181.27)',,

                        transfers: [

                            sshTransfer(

                                cleanRemote: false,

                                excludes: '',

                                execCommand: '''#!/bin/bash

                                  #进入远程服务器的目录

                                  project_dir=/usr/local/nginx/qmp_pc_ddm_${DEPLOYPATH}/${DEPLOYPATH}

                                  if [ ${DEPLOYPATH} == "ddm"  ]; then

                                     project_dir=/usr/local/nginx/qmp_pc_ddm/dist

                                  fi

                                  cd $project_dir



                                  sudo mv /home/jenkins/qmp_pc_ddm/*.tar.gz  .



                                  #找到新的压缩包

                                  new_dist=`ls -ltr *.tar.gz | awk \'{print $NF}\' |tail -1`



                                  #解压缩

                                  sudo tar -zxvf $new_dist



                                  #删除压缩包

                                  sudo rm *.tar.gz



                                  #发布完成

                                  echo "环境发布完成"

                                ''',

                                execTimeout: 120000,

                                flatten: false,

                                makeEmptyDirs: false,

                                noDefaultExcludes: false,

                                patternSeparator: '[, ]+',

                                remoteDirectory: 'qmp_pc_ddm',

                                remoteDirectorySDF: false,

                                removePrefix: 'dist/',

                                sourceFiles: 'dist/*.tar.gz'

                            )

                        ],

                        usePromotionTimestamp: false,

                        useWorkspaceInPromotion: false,

                        verbose: false

                    )

                ]

            )

          }

        }

    }

    post {

        success  {

          echo 'success.'

          deleteDir()

        }

    }

}

接下来，我们一起来解读下这个文件。

首先，所有的指令都是包裹在 pipeline{} 块中，

agent

enkins 可以在任何可用的代理节点上执行构建任务。

environment

用于定义环境变量，它们会保存为 Groovy 变量和 Shell 环境变量：定义流水线中的所有步骤可用的环境变量 temPath，在后续可通过 $tmpPath 来使用；

环境变量可以在全局定义，也可在 stage 里单独定义，全局定义的在整个生命周期里可以使用，在 stage 里定义的环境变量只能在当前步骤使用。

Jenkins 有一些内置变量也可以通过 env 获取（env 也可以读取用户自己定义的环境变量）。

steps {

    echo "Running ${env.BUILD_ID} on ${env.JENKINS_URL}"

}

这些变量都是 String 类型，常见的内置变量有：

• BUILD_NUMBER：Jenkins 构建序号；


• BUILD_TAG：比如 jenkins-${JOB_NAME}-${BUILD_NUMBER}；


• BUILD_URL：Jenkins 某次构建的链接；


• NODE_NAME：当前构建使用的机器

parameters

定义流水线中可以接收的参数，如上面脚本中的 gitParameter，只有安装了 Git Parameters 插件后才能使用，name 设置为delopyTag，在后续可通过 ${params.delopyTag} 来使用；

还有以下参数类型可供添加：

parameters {

  booleanParam(name: 'isOSS', defaultValue: true, description: '是否上传OSS')

  choice(name: 'select', choices: ['A', 'B', 'C'], description: '选择')

  string(name: 'temp', defaultValue: '/temp', description: '默认路径')

  text(name: 'showText', defaultValue: 'Hello\nWorld', description: '')

  password(name: 'Password', defaultValue: '123', description: '')

}

triggers

定义了流水线被重新触发的自动化方法，上面的配置是：当 Git 仓库有新的 push 操作时触发构建

stages 阶段

• 阶段一：拉取代码
  
  

  git：拉取代码，参数 branch 为分支名，我们使用上面定义的 ${params.delopyTag}，credentialsId 以及 url，如果不知道怎么填，可以在 流水线语法 -> 片段生成器 中填写对应信息后，自动生成，如下：

  
  

  

  
  

  再复制到此处即可。



• 阶段二：安装依赖
  
  

  在 steps 中，sh 是 Jenkins pipeline 的语法，通过它来执行 shell 脚本。

  
  

  #!/bin/bash表示使用 bash 脚本；
  source /etc/profile 用于将指定文件中的环境变量和函数导入当前 shell。

  
  

  执行 yarn 安装依赖。



• 阶段三：编译
  
  

  执行 yarn build 打包，

  
  

  if [ -d dist ]; 是 shell 脚本中的语法，用于测试 dist 目录是否存在，通过脚本将打包产物打成一个压缩包。



• 阶段四：解压
  
  

  将上步骤生成的压缩包，通过 Publish over SSH 发送到指定服务器的指定位置，执行 Shell 命令解压。

  
  

  不会写 Publish over SSH 怎么办？同样，可以在 流水线语法 -> 片段生成器 中填写对应信息后，自动生成，如下：

  
  

  

post

当流水线的完成状态为 success，输出 success。

deleteDir() 函数用于删除当前工作目录中的所有文件和子目录。这通常用于清理工作区，确保在下一次构建之前工作区是干净的，以避免由于残留文件或目录引起的潜在问题。

构建看看效果

可以直接通过 Console Output 查看控制台输出，当然在流水线项目中自然要通过流水线去查看了。

通过项目中的 Jenkinsfile 构建

再把对应的 Pipeline script 代码复制到对应代码仓库的 Jenkinsfile 文件，设置为 Pipeline script from SCM，填写 git 信息。

正常情况下，Jenkins 会自动检测代码仓库的 Jenkinsfile 文件，如果选择的文件没有 Jenkinsfile 文件时就会报错，如下：

正常按照流水线的执行流程，打开 Blue Ocean，查看构建结果，如下：

片段生成器

如果你觉得上述代码手写麻烦，刚开始时又不会写，那么就可以使用片段代码生成器来帮助我们生成流水线语法。

进入任务构建页面，点击 流水线语法 进入：

配置构建过程遇到的问题

总结

本文对 Jenkins 的基本教程就到此为止了，主要讲了 Jenkins 的安装部署，FreeStyle project 和 Pipeline 的使用，以及插件安装、配置等。如果想要学，跟着我这个教程实操一遍，Jenkins 就基本掌握了，基本工作中遇到的问题都能解决，剩下的就只能在实际工作中慢慢摸索了。

再说回最初的话题，前端需不需要学习 Jenkins。我认为接触新的东西，然后学习并掌握，拓宽了技术面，虽然是一种压力，也是得到了成长的机会，在这个前端技术日新月异的时代，前端们不仅要熟练掌握前端技术，还需要具备一定的后端知识和自动化构建能力，才能不那么容易被大环境淘汰。

以上就是本文的全部内容，希望这篇文章对你有所帮助，欢迎点赞和收藏 🙏，如果发现有什么错误或者更好的解决方案及建议，欢迎随时联系。

或许从诞生那天起，LangChain 就注定是一个口碑两极分化的产品。

看好 LangChain 的人欣赏它丰富的工具和组建和易于集成等特点，不看好 LangChain 的人，认为它注定失败 —— 在这个技术变化如此之快的年代，用 LangChain 来构建一切根本行不通。

夸张点的还有：

「在我的咨询工作中，我花了 70% 的精力来说服人们不要使用 langchain 或 llamaindex。这解决了他们 90% 的问题。」

最近，一篇 LangChain 吐槽文再次成为热议焦点：

作者 Fabian Both 是 AI 测试工具 Octomind 的深度学习工程师。Octomind 团队会使用具有多个 LLM 的 AI Agent 来自动创建和修复 Playwright 中的端到端测试。

这是一个持续一年多的故事，从选择 LangChain 开始，随后进入到了与 LangChain 顽强斗争的阶段。在 2024 年，他们终于决定告别 LangChain。

让我们看看他们经历了什么：

「LangChain 曾是最佳选择」

我们在生产中使用 LangChain 超过 12 个月，从 2023 年初开始使用，然后在 2024 年将其移除。

在 2023 年，LangChain 似乎是我们的最佳选择。它拥有一系列令人印象深刻的组件和工具，而且人气飙升。LangChain 承诺「让开发人员一个下午就能从一个想法变成可运行的代码」，但随着我们的需求变得越来越复杂，问题也开始浮出水面。

LangChain 变成了阻力的根源，而不是生产力的根源。

随着 LangChain 的不灵活性开始显现，我们开始深入研究 LangChain 的内部结构，以改进系统的底层行为。但是，由于 LangChain 故意将许多细节做得很抽象，我们无法轻松编写所需的底层代码。

众所周知，人工智能和 LLM 是瞬息万变的领域，每周都会有新的概念和想法出现。而 LangChain 这样围绕多种新兴技术创建的抽象概念，其框架设计很难经得起时间考验。

LangChain 为什么如此抽象

起初，当我们的简单需求与 LangChain 的使用假设相吻合时，LangChain 还能帮上忙。但它的高级抽象很快就让我们的代码变得更加难以理解，维护过程也令人沮丧。当团队用在理解和调试 LangChain 的时间和用在构建功能上的时间一样时，这可不是一个好兆头。

LangChain 的抽象方法所存在的问题，可以通过「将一个英语单词翻译成意大利语」这一微不足道的示例来说明。

下面是一个仅使用 OpenAI 软件包的 Python 示例：

这是一段简单易懂的代码，只包含一个类和一个函数调用。其余部分都是标准的 Python 代码。

将其与 LangChain 的版本进行对比：

代码大致相同，但相似之处仅此而已。

我们现在有三个类和四个函数调用。但令人担忧的是，LangChain 引入了三个新的抽象概念：

• Prompt 模板： 为 LLM 提供 Prompt；


• 输出解析器： 处理来自 LLM 的输出；


• 链： LangChain 的「LCEL 语法」覆盖 Python 的 | 操作符。

LangChain 所做的只是增加了代码的复杂性，却没有带来任何明显的好处。

这种代码对于早期原型来说可能没什么问题。但对于生产使用，每个组件都必须得到合理的理解，这样在实际使用条件下才不至于意外崩溃。你必须遵守给定的数据结构，并围绕这些抽象设计应用程序。

让我们看看 Python 中的另一个抽象比较，这次是从 API 中获取 JSON。

使用内置的 http 包：

使用 requests 包：

高下显而易见。这就是好的抽象的感觉。

当然，这些都是微不足道的例子。但我想说的是，好的抽象可以简化代码，减少理解代码所需的认知负荷。

LangChain 试图通过隐藏细节，用更少的代码完成更多的工作，让你的生活变得更轻松。但是，如果这是以牺牲简单性和灵活性为代价的，那么抽象就失去了价值。

LangChain 还习惯于在其他抽象之上使用抽象，因此你往往不得不从嵌套抽象的角度来思考如何正确使用 API。这不可避免地会导致理解庞大的堆栈跟踪和调试你没有编写的内部框架代码，而不是实现新功能。

LangChain 对开发团队的影响

一般来说，应用程序大量使用 AI Agent 来执行不同类型的任务，如发现测试用例、生成 Playwright 测试和自动修复。

当我们想从单一 Sequential Agent 的架构转向更复杂的架构时，LangChain 成为了限制因素。例如，生成 Sub-Agent 并让它们与原始 Agent 互动。或者多个专业 Agent 相互交互。

在另一个例子中，我们需要根据业务逻辑和 LLM 的输出，动态改变 Agent 可以访问的工具的可用性。但是 LangChain 并没有提供从外部观察 Agent 状态的方法，这导致我们不得不缩小实现范围，以适应 LangChain Agent 的有限功能。

一旦我们删除了它，我们就不再需要将我们的需求转化为适合 LangChain 的解决方案。我们只需编写代码即可。

那么，如果不使用 LangChain，你应该使用什么框架呢？也许你根本不需要框架。

**我们真的需要构建人工智能应用程序的框架吗？

**

LangChain 在早期为我们提供了 LLM 功能，让我们可以专注于构建应用程序。但事后看来，如果没有框架，我们的长期发展会更好。

LangChain 一长串的组件给人的印象是，构建一个由 LLM 驱动的应用程序非常复杂。但大多数应用程序所需的核心组件通常如下：

• 用于 LLM 通信的客户端


• 用于函数调用的函数 / 工具 


• 用于 RAG 的向量数据库


• 用于跟踪、评估等的可观察性平台。

Agent 领域正在快速发展，带来了令人兴奋的可能性和有趣的用例，但我们建议 —— 在 Agent 的使用模式得到巩固之前，暂时保持简单。人工智能领域的许多开发工作都是由实验和原型设计驱动的。

以上是 Fabian Both 一年多来的切身体会，但 LangChain 并非全然没有可取之处。

另一位开发者 Tim Valishev 表示，他会再坚持使用 LangChain 一段时间：

我真的很喜欢 Langsmith：

• 开箱即用的可视化日志 


• Prompt playground，可以立即从日志中修复 Prompt，并查看它在相同输入下的表现 


• 可直接从日志轻松构建测试数据集，并可选择一键运行 Prompt 中的简单测试集（或在代码中进行端到端测试） 


• 测试分数历史 


• Prompt 版本控制 

而且它对整个链的流式传输提供了很好的支持，手动实现这一点需要一些时间。

何况，只依靠 API 也是不行的，每家大模型厂商的 API 都不同，并不能「无缝切换」。

你怎么看？

原文链接：http://www.octomind.dev/blog/why-we…

nest 很多功能基于装饰器实现，我们有必要好好了解下有哪些装饰器：
创建 nest 项目：

nest new all-decorator -p npm

@Module({})

这是一个类装饰器，用于定义一个模块。
模块是 Nest.js 中组织代码的单元，可以包含控制器、提供者等：

@Controller() 和 @Injectable()

这两个装饰器也是类装饰器，前者控制器负责处理传入的请求和返回响应，后者定义一个服务提供者，可以被注入到控制器或其他服务中。
通过 @Controller、@Injectable 分别声明 controller 和 provider：

@Optional、@Inject

创建可选对象（无依赖注入），可以用 @Optional 声明一下，这样没有对应的 provider 也能正常创建这个对象。

注入依赖也可以用 @Inject 装饰器。

@Catch

filter 是处理抛出的未捕获异常，通过 @Catch 来指定处理的异常：

@UseXxx、@Query、@Param

使用 @UseFilters 应用 filter 到 handler 上：


除了 filter 之外，interceptor、guard、pipe 也是这样用：

@Body

如果是 post、put、patch** **请求，可以通过 @Body 取到 body 部分：

我们一般用 dto 定义的 class 来接收验证请求体里的参数。

@Put、@Delete、@Patch、@Options、@Head

@Put、@Delete、@Patch、@Options、@Head 装饰器分别接受 put、delete、patch、options、head 请求：

@SetMetadata

通过 @SetMetadata 指定 metadata，作用于 handler 或 class

然后在 guard 或者 interceptor 里取出来：

@Headers

可以通过 @Headers 装饰器取某个请求头或者全部请求头：

@Ip

通过 @Ip 拿到请求的 ip，通过 @Session 拿到 session 对象：

@HostParam

@HostParam 用于取域名部分的参数。
下面 host 需要满足 xxx.0.0.1 到这个 controller，host 里的参数就可以通过 @HostParam 取出来：

@Req、@Request、@Res、@Response

前面取的这些都是 request 里的属性，当然也可以直接注入 request 对象：

@Req 或者 @Request 装饰器，这俩是同一个东西。

使用 @Res 或 @Response 注入 response 对象，但是注入 response 对象之后，服务器会一直没有响应。
因为这时候 Nest 就不会把 handler 返回值作为响应内容了。我们可以自己返回响应：

Nest 这么设计是为了避免相互冲突。
如果你不会自己返回响应，可以设置 passthrough 为 true 告诉 Nest：

@Next

除了注入 @Res 不会返回响应外，注入 @Next 也不会。
当你有两个 handler 来处理同一个路由的时候，可以在第一个 handler 里注入 next，调用它来把请求转发到第二个 handler。

@HttpCode

handler 默认返回的是 200 的状态码，你可以通过 @HttpCode 修改它：

@Header

当然，你也可以修改 response header，通过 @Header 装饰器：

起因

有一天老爸找我，他们公司每年都要在线看视频学习，要花费很多时间，问我有没有办法可以自动学习。

在这之前，我还给我老婆写了个浏览器插件，解决了她的在线学习问题，她学习的是一个叫好医生的学习网站，我通过研究网站的接口和代码，帮她开发出了一键学习全部课程和自动考试的插件，原本需要十来天的学习时间，分分钟就解决了。

有兴趣的可以看一下，好医生自动学习+考试插件源码。

正因为这次的经历，我直接接下了这个需求，毕竟可以在家人面前利用自己的能力去帮他们解决问题，是一件非常骄傲的事。

事情并没有那么简单

我回家一看，他们的学习平台是个桌面端的软件（毕竟是银行的平台，做的比那个好医生严谨的多），内嵌的浏览器，无法打开控制台，更没办法装插件，甚至视频学习调了什么接口，有什么漏洞都无法发现，我感觉有点无能为力。

但是牛逼吹出去了，也得想办法做。

技术选型

既然没办法找系统漏洞去快速学习，那只能按部就班的去听课了，我第一想到的方式是用按键精灵写个脚本，去自动点击就可以了。但是我爸又想给他的同事用，再教他们用按键精灵还是有点上手成本的，所以我打算自己开发一个小工具去实现。

由于我是个前端开发者，做桌面端首先想到的是 Electron，因为我有一些开发经验，所以并不难，但打包后的体积太大，本来一个小工具，做这么大，这不是显得我技术太烂嘛。

所以我选择了 tauri 去开发。

需求分析

首先我想到的方式就是：

例如，本节课程学习后，会弹出提示框，进入下一节学习，那么可以识别这个按钮，如果屏幕出现这个按钮，则点击，从而实现自动学习的目的。

我还给它起了个很形象的名字，叫做打地鼠。

由于要点击的不一定只有一个下一节，可能还有其他章节的可能要学习，所以还实现了多任务执行，这样可以识别多个位置。

有兴趣可以看一下源码。

零基础入门 rust

Tauri 已经提供了很多可以在前端调用的接口去实现很多桌面端的功能，但也不能完全能满足我本次开发的需求，所以还是要学习一点 rust 的语法。

这里简单说一下我学到的一些简单语法，方便大家快速入门。由于功能简单，我们并不需要了解 rust 那些高深的内容，了解基础语法即可，不然想学会 rust 我觉得真心很难。我们完全可以先入门，再深入。

适合人群

有一定其他编程语言(C/Java/Go/Python/JavaScript/Typescript/Dart等)基础。你至少得会写点代码是吧。

环境安装

推荐使用 rustup 安装 rust，rustup 是官方提供的的安装工具。

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

安装后，检查版本，这类似安装 node 后查看版本去验证是否成功安装。

rustc --version



>>> rustc 1.73.0 (cc66ad468 2023-10-03)

cargo 是 rust 官方的包管理工具，类似 npm，这里也校验一下是否成功安装。

cargo --version

如果提示不存在指令，重新打开终端再尝试。

编辑器

官方推荐 Clion，是开发 rust 首选开发工具。

不过作为前端，我们依然希望可以使用 vscode 去开发，当然，这也是没有问题的。

vscode 需要搭配 rust-analyzer 一起使用。

除了上面提到的两个命令，还有 rustup 命令也可以直接使用了：

rustup component add rust-analyzer

执行后就都配置好了，可以进行语法的学习了。

变量与常量的声明

定义变量和常量的声明 javascript 和 rust 是一样的，都是通过 let 和 const，但是在定义变量时还是有一些区别的：

• 默认情况下，变量是不可变的。（这点对于前端同学来说是不是很奇怪？）


• 如果你想定义一个可变的变量，需要在变量名前面加上 mut。

let x = 1;

x = 2; ❌

let mut x = 1;

x = 2; ✅

如果你不想用 mut，你也可以使用相同的名称声明新的变量：

let x = 1;

let x = x + 1;

Rust 里常量的命名规范是使用全大写字母，每个单词之间使用下划线分开，虽然 JS 没有强制的规范，但是我们也是这么做的。

数据类型

对于只了解 javascript 的同学，这个是非常重要的一环，因为 rust 需要在定义变量时做出类型的定义。即使是有过 typescript 开发经验的同学，这里也有着非常大的区别。这里只说一些与 js 区别较大的地方。

数字

首先 ts 对于数字的类型都是统一的 number，但是 rust 区别就比较大了，分为有符号整型，无符号整型，浮点型。

有 i8、i16、i32、i64、i128、u8、u16、u32、u64、isize、usize、f32、f64。

虽然上面看起来有这么多种类型去定义一个数字类型，实际上它们只是去定义了这个值所占用的空间，新手其实不用太过于纠结这里。如果你不知道应该选择哪种类型，直接使用默认的i32即可，速度也很快。有符号就是分正负(+,-)，无符号只有正数。浮点型在现代计算机里上 f64 和 f32 运行速度差不多，f64 更加精确，所以不用太纠结。

数组

数组定义也有很大区别，你需要一开始就定义好数组的长度：

let a: [i32; 5] = [0; 5];

这表示定义一个包含 5 个元素的数组，所有元素都初始化为 0。一旦定义，数组的大小就不能改变了。

这是不是让前端同学很难理解，那么如何定义一个可变的数组呢？这好像更符合前端的思维。

在 Rust 中，Vec 是一个动态数组，也就是说，它可以在运行时增加或减少元素。

let v: Vec<i32> = Vec::new();

v.push(4);

这是不是更符合前端的直觉？毕竟后面我们要使用鼠标框选一个范围的颜色，这个颜色数组是不固定的，所以要用到 Vec。

数据类型就说到这，其他的有兴趣自行了解即可。

引用包

rust 同 javascript 一样，也可以引入其他包，但语法上就不太一样了，例如：

use autopilot::{geometry::Point, screen, mouse};

强行翻译成 es module 引入：

import { Point, screen, mouse } from 'autopilot';

看到 :: 是不是有点懵逼，javascript 可没有这样的东西，你可以直觉的把它和 . 想象成一样就行。

:: 主要用于访问模块（module）或类型（type）的成员。例如，你可以使用 :: 来访问模块中的函数或常量，或者访问枚举的成员。

. 用于访问结构体（struct）、枚举（enum）或者 trait 对象的实例成员，包括字段（field）和方法（method）。

其他语法

循环：

for i in 0..colors.len() {}

条件判断：

if colors[i] != screen_colors[i] {



}

他们就是少了括号，还有一些高级的语法是 ES 没有的，这都很好理解。

那么我说这样就算入门了，不算过分吧？如果你要学一个语言，千万别因为它难而不敢上手，你直接上手去做，遇坑就填，你会进步很快。

如果你觉得这样很难写代码，那么我建议你买个 copilot 或者平替通义灵码，你上手写点小东西应该就不成问题了，毕竟我就这样就开始做了。

软件开发

Tauri 官网翻译还不全，读起来可能有点吃力，借助翻译工具将就着看吧，我有心帮大家翻译，但是提了 pr，好几天也没人审核。

你可以把 tauri 当作前端和后端不分离的项目，webview 就是前端，rust 写后端。

创建项目

tauri 提供了很多方式去帮你创建一个新的项目：

这里初始化一个 vite + vue + ts 的项目：

最后的目录结构可以看一下：

src 就是前端的目录。

src-tauri 就是后端的目录。

前端

前端是老本行，不想说太多的东西，大家都很熟悉，把页面写出来就可以了。

值得一提的就是 tauri 提供的一些接口，这些接口可以让我们实现一些浏览器上无法实现的功能。

与后端通讯

import { invoke } from "@tauri-apps/api";



invoke('event_name', payload)

通过 invoke 可以调用 rust 方法，并通过 payload 去传递参数。

窗口间传递信息

这里的窗口指的是软件的窗口，不是浏览器的标签页。由于我们要框选一块显示器上的区域，所以要创建一个新的窗口去实现，而选择后要将数据传递给主窗口。

import { listen } from '@tauri-apps/api/event';



listen<{ index: number}>("location", async (event) => {

  const index = event.payload.index;

  // ...

})

获取窗口实例

例如隐藏当前窗口的操作：

import { getCurrent } from '@tauri-apps/api/window';



const win = getCurrent()

win.hide() // 显示窗口即 win.show()

与之相似的还有：

• appWindow 获取主窗口实例。


• getAll 获取所有窗口实例，可以通过 label 来区分窗口。

最主要的是 WebviewWindow，可以通过他去创建一个新的窗口。

const screenshot = new WebviewWindow("screenshot", {

  title: "screenshot",

  decorations: false,

  // 对应 views/screenshot.vue

  url: `/#/screenshot?index=${props.index}`,

  alwaysOnTop: true,

  transparent: true,

  hiddenTitle: true,

  maximized: true,

  visible: false,

  resizable: false,

  skipTaskbar: false,

})

这里我们创建了一个最大化、透明的窗口，且它位于屏幕最上方，页面指向就是 vue-router 的路由，index 是因为我们不确定要创建多少个窗口，用于区分。

可以通过创建这样的透明窗口，然后实现一个框选区域的功能，这对于前端来说，并不难。

例如鼠标点击左键，滑动鼠标，再松开左键，绘制这个矩形，再加一个按钮。

随后将位置信息传递给主窗口，并关闭这个透明窗口。

后端

首先，src-tauri/src/main.rs 是已经创建好的入口文件，里面已有一些内容，不用都了解。

暴露给前端的方法

tauri::Builder::default().invoke_handler(tauri::generate_handler![scan_once, ...])

通过 invoke_handler 可以暴露给前端 invoke 调用的方法。

! 在 rust 中是指宏调用，主要是方便，并不是 javascript 里的非的含义，这里注意下。

获取屏幕颜色

这里为了性能，我只获取了 x 起始位置到 x 结束位置，y 轴取中间一行的颜色。

use autopilot::{geometry::Point, screen};



pub fn scan_colors(start_x: f64, end_x: f64, y: f64) -> Vec<[u8; 3]> {

    // 双重循环，根据 start_x, end_x, y 定义坐标数组

    let mut points: Vec<Point> = Vec::new();

    let mut x = start_x;

    while x < end_x {

        points.push(Point::new(x, y));

        x += 1.0;

    }

    // 循环获取坐标数组的颜色

    let mut colors: Vec<[u8; 3]> = Vec::new();

    for point in points {

        let pixel = screen::get_color(point).unwrap();

        colors.push([pixel[0], pixel[1], pixel[2]]);

    }

    return colors;

}

这样就获取到一组颜色数组，包含了 RGB 信息。

这里安装了一个叫 autopilot 的包，可以通过 cargo add autopilot 安装，他可以获取屏幕的颜色，也可以操作鼠标。

鼠标操作

使用 autopilot::mouse 可以进行鼠标操作，移动至 x、y 坐标、病点击鼠标左键。

use autopilot::{geometry::Point, mouse};



mouse::move_to(Point::new(x, y));

mouse::click(mouse::Button::Left, );

配置权限

在 src-tauri/tauri.conf.json 中配置 allowlist，如果不想了解都有哪些权限，直接 all: true，全部配上，以后再慢慢了解。

"tauri": {

    "macOSPrivateApi": true,

    "allowlist": {

      "all": true,

    },

}

注意 mac 上如果使用透明窗口，还需要配置 macOSPrivateApi。

整体流程就是这样的，其他都是细节处理，有兴趣可以看下源码。

构建

我爸的电脑是 windows，而我的是 mac，所以需要构建一个 windows 安装包，但是 tauri 依赖本机库和开链，所以想跨平台编译是不可能的，最好的方法就是托管在 GitHub Actions 这种 CI/CD 平台去做。

在项目下创建 .github/workflows/release.yml，它将会在你发布 tag 时触发构建。

name: Release



on:

  push:

    tags:

      - 'v*'

  workflow_dispatch:



concurrency:

  group: release-${{ github.ref }}

  cancel-in-progress: true



jobs:

  publish:

    strategy:

      fail-fast: false

      matrix:

        platform: [macos-latest, windows-latest]



    runs-on: ${{ matrix.platform }}

    steps:

      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v2

        with:

          version: 8

          run_install: true



      - name: Use Node.js

        uses: actions/setup-node@v4

        with:

          node-version: 20

          cache: 'pnpm'



      - name: install Rust stable

        uses: actions-rs/toolchain@v1

        with:

          toolchain: stable



      - name: Build Vite + Tauri

        run: pnpm build



      - name: Create release

        uses: tauri-apps/tauri-action@v0

        env:

          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

        with:

          tagName: v__VERSION__ # the action automatically replaces \_\_VERSION\_\_ with the app version

          releaseName: 'v__VERSION__'

          releaseBody: 'See the assets to download and install this version.'

          releaseDraft: true

          prerelease: false

这里提供一个实例，具体情况具体修改。

secrets.GITHUB_TOKEN 并不需要你配置，他是自动获取的，主要是获得权限去操作你的仓库。因为构建完成会自动创建 release，并上传安装包。

你还需要修改一下仓库的配置：

选中 Read and write permissions，勾选
Allow GitHub Actions to create and approve pull requests。

当你发布 tag 后，会触发 action 执行。

可见，打包速度真的很慢。

Actions 执行完毕后，进入 Releases 页面，可以看到安装包已经发布。

总结

• 关于 tauri 和 electron，甚至是 flutter、qt 这种技术方向没必要讨论谁好谁坏，主要还是考虑项目的痛点，去选择适合自己的方式，没必要捧高踩低。


• Rust 真的很难学，我上文草草几句入门，其实并没有那么简单，刚上手会踩很多坑，甚至无从下手不会写代码。我主要的目的是希望大家有想法就要着手去做，毕竟站在岸上学不会游泳。Flutter 使用 dart，我曾经写写过两个 app，相比于 rust，dart 对于前端同学来说可以更轻松的学习。


• Tauri 我目前还是比较看好，也很看好 rust，大家有时间的话还是值得学习一下，尤其是 2.0 版本还支持了移动端。


• 看到很多同学，在学习一门语言或技术时，总是不知道做什么，不只是工作，其实我们身边有很多事情都可以去做，可能只是你想不到。我平时真的是喜欢利用代码去搞一些奇奇怪怪的事，例如我写过 vscode 摸鱼插件、自动学习视频的 chrome 插件、互赞平台、小电影爬虫等等，这些都是用 javascript 就实现的。你可以做的很多，给自己提一个需求，然后不要怕踩坑，踩坑的过程是你进步最快的过程，享受它。

方向完全搞错了？

大语言模型（LLM）为什么空间智能不足，GPT-4 为什么用语言以外的数据训练，就能变得更聪明？现在这些问题有 「标准答案」了。

近日，一篇麻省理工学院（MIT）等机构发表在顶级学术期刊《自然》杂志的文章观察到，人类大脑生成和解析语言的神经网络并不负责形式化推理，而且提出推理并不需要语言作为媒介。

这篇论文声称「语言主要是用于交流的工具，而不是思考的工具，对于任何经过测试的思维形式都不是必需的」，引发了科技领域社区的大讨论。

难道真的如语言学家乔姆斯基所言，追捧 ChatGPT 是浪费资源，大语言模型通向通用人工智能（AGI）的路线完全错了？

让我们看看这篇论文《Language is primarily a tool for communication rather than thought》是怎么说的。

论文链接：http://www.nature.com/articles/s4…

语言是人类智能的一个决定性特征，但它所起的作用或多或少一直存在争议。该研究提供了神经科学等相关学科角度的最新证据，以论证现代人类的语言是一种交流工具，这与我们使用语言进行思考的流行观点相反。

作者首先介绍了支持人类语言能力的大脑网络。随后回顾语言和思维双重分离的证据，并讨论语言的几种特性，这些特性表明语言是为交流而优化的。该研究得出结论认为，尽管语言的出现无疑改变了人类文化，但语言似乎并不是复杂思维（包括符号思维）的先决条件。相反，语言是传播文化知识的有力工具，它可能与我们的思维和推理能力共同进化，并且只反映了人类认知的标志性复杂性，而不是产生这种复杂性。

图 1

研究证据挑战了语言对于思维的重要性。如图 1 所示，使用 fMRI 等成像工具，我们可以识别完整、健康的大脑中的语言区域，然后检查在完成需要不同思维形式的任务时，语言区域的相关响应。

 人类大脑中的语言网络

从人脑的生物学结构来看，语言生成和语言理解由左半球一组相互连接的大脑区域支持，通常称为语言网络（图 1a；Box 2 描述了它与语言神经生物学经典模型的关系）。

Box 2。许多教科书仍然使用 Wernicke 提出的语言神经基础模型，并由 Lichteim 和 Geschwind 进行了阐述和修订。该模型包括两个皮层区域：Broca 区位于下额叶皮层，Wernicke 区位于后上颞叶皮层。这两个区域分别支持语言产生和理解，并通过一条背侧纤维束（弓状束）连接。

语言网络有两个非常重要的特性：

首先，语言区域表现出输入和输出模态的独立性，这是表征抽象性的关键特征。主要表现为在理解过程中，这些大脑区域对跨模态（口头、书面或手语）的语言输入做出反应。同样，在语言生成过程中，无论我们是通过口语还是书面语来产生信息，这些区域都是活跃的。这些区域支持语言理解和生成（图 1a）这一事实表明，它们很可能存储了我们的语言知识，这对于编码和解码语言信息都是必需的。

其次，语言区还能对词义和句法结构进行表征和处理。特别是，关于脑磁图和颅内记录研究的证据表明，语言网络的所有区域都对词义以及词间句法和语义依赖性敏感（图 1a）。总之，语言网络中语言表征的抽象性以及网络对语言意义和结构的敏感性使其成为评估语言在思维和认知中的作用假设的明确目标（(Box 3）。

我们对人类语言和认知能力，以及它们之间关系的理解仍然不完整，还有一些悬而未决的问题：

• 语言表征的本质是什么？


• 思维是否依赖于符号表征？


• 儿童学习语言时，语言网络是如何成长的？

语言对于任何经过检验的思维形式都不是必需的

经典的方法是通过研究大脑损伤或疾病的个体来推断大脑与行为之间的关联和分离。这种方法依赖于观察大脑某部分受损时个体行为的变化，从而推测不同大脑区域的功能和行为之间的联系。

有证据表明 —— 有许多个体在语言能力上有严重的障碍，影响到词汇和句法能力，但他们仍然表现出在许多思考形式上的完整能力：他们可以解决数学问题，进行执行规划和遵循非言语指令，参与多种形式的推理，包括形式逻辑推理、关于世界的因果推理和科学推理（见图 1b）。  

研究表明，尽管失去了语言能力，一些患有严重失语症的人仍然能够进行所有测试形式的思考和推理，他们在各种认知任务中的完整表现就是明证。他们根本无法将这些想法映射到语言表达上，无论是在语言生成中（他们无法通过语言向他人传达自己的想法），还是在理解中（他们无法从他人的单词和句子中提取意义）（图 1b）。当然，在某些脑损伤病例中，语言能力和（某些）思维能力都可能受到影响，但考虑到语言系统与其他高级认知系统的接近性，这是可以预料的。

尤其是一些聋哑儿童，他们长大后很少或根本没有接触过语言，因为他们听不见说话，而他们的父母或看护人不懂手语。缺乏语言接触会对认知的许多方面产生有害影响，这是可以预料的，因为语言是了解世界的重要信息来源。尽管如此，语言剥夺的个体无疑表现出复杂的认知功能能力：他们仍然可以学习数学、进行关系推理、建立因果链，并获得丰富而复杂的世界知识。换句话说，缺乏语言表征并不会使人从根本上无法进行复杂的（包括符号的）思考，尽管推理的某些方面确实表现出延迟。因此，在典型的发展中，语言和推理是平行发展的。

完整的语言并不意味着完整的思维

以上证据表明，迄今为止测试的所有类型的思维都可以在没有语言的情况下实现。

接下来，论文讨论了语言和思维双重分离的另一面：与语言介导思维的观点相反，完整的语言系统似乎并不意味着完整的推理能力。

人类语言是由交流压力塑造的。

来自发育性和后天性脑部疾病的证据表明，即使语言能力基本完好，也可能存在智力障碍。

例如，有些遗传疾病导致智力受损程度不同，但患有这些疾病的人的语言能力似乎接近正常水平；还有一些精神层面有缺陷的人，会影响思考和推理能力，但同样不会影响语言。最后，许多获得性脑损伤的个体在推理和解决问题方面表现出困难，但他们的语言能力似乎完好无损。换句话说，拥有完整的语言系统并不意味着自动具备思考能力：即使语言能力完好无损，思考能力也可能受损。

总的来说，这篇论文回顾了过去二十年的相关工作。失语症研究的证据表明：所有经过检验的思维形式在没有语言的情况下都是可能的。fMRI 成像证据表明：参与多种形式的思考和推理并不需要语言网络。因此，语言不太可能成为任何形式思维的关键基础。

MIT 研究得出结论的同时，顶尖 AI 领域学者最近也发表了对大模型发展的担忧。上个星期四 Claude 3.5 的发布号称拥有研究生水平的推理能力，提升了行业的标准。不过也有人表示经过实测可见，它仍然具有 Transformer 架构的局限性。

对此，图灵奖获得者 Yann LeCun 表示，问题不在于 Transformer，而是因为 Claude 3.5 仍然是一个自回归大模型。无论架构细节如何，使用固定数量的计算步骤来计算每个 token 的自回归 LLM 都无法进行推理。

LeCun 也评论了这篇 Nature 论文，对思维不等于语言表示赞同。

对此，你怎么看？

参考内容：

news.ycombinator.com/item?id=407…

x.com/ylecun/stat…

之前使用 iconfont 是非常方便的，上传之后立马生效，项目里面直接引用即可，但是现在因为政策的收紧，每次上传图标都要等待十几分钟二十分钟的审核时间，这怎么能忍，有这个时间我都能写一个页面了好吧。

忍受不了就自己做，说干就干，于是我写了一个 svg 转图标字体的脚手架，所有的内容都自己维护，不再受制于人，感觉就是爽。

svg2font: 一个高效的 SVG 图标字体生成工具

github.com/tenadolante…

在现代 Web 开发中，使用图标是一种常见的做法。图标不仅能美化界面，还能提高可用性和可访问性。传统上，我们使用图片文件(如 PNG、JPG 等)来显示图标，但这种方式存在一些缺陷，例如图片文件较大、不能任意缩放、无法通过 CSS 设置颜色等。相比之下，使用字体图标具有许多优势，如文件体积小、可无限缩放、可通过 CSS 设置颜色和阴影等。

svg2font 就是一个用于将 SVG 图标转换为字体图标的工具，它可以帮助我们轻松地在项目中集成和使用字体图标。本文将详细介绍 svg2font 的使用方法、应用场景和注意事项。

安装

svg2font 是一个基于 Node.js 的命令行工具，因此需要先安装 Node.js 环境。安装完成后，可以使用 npm 或 yarn 在项目中安装 svg2font:

# 使用npm

npm install @tenado/svg2font -D



# 使用yarn

yarn add @tenado/svg2font -D

初始化配置

安装完成后，需要初始化 svg2font 的配置文件。在项目根目录执行以下命令:

npx svg2font init

该命令会在项目根目录下生成一个 svg2font.config.js 文件，内容如下:

module.exports = {

  inputPath: "src/assets/svgs", // SVG图标文件夹路径

  outputPath: "src/assets/font", // 生成字体文件的输出路径

  fontFamily: "tenadoIcon", // 字体名称

  fontPrefix: "", // 字体前缀

};

你可以根据实际需求修改这些配置项。

生成字体图标

配置完成后，就可以执行以下命令生成字体图标了:

npx svg2font sync

该命令会读取 inputPath 指定的 SVG 图标文件夹，将其中的 SVG 文件转换为字体文件(包括.eot、.ttf、.woff、.woff2 等格式)，并输出到 outputPath 指定的路径下。同时，它还会生成一个 config.json 文件，记录了每个图标的 Unicode 编码和 CSS 类名。

在项目中使用字体图标

生成字体文件后，需要在项目中引入相应的 CSS 文件，才能正常使用字体图标。svg2font 会自动生成一个 index.min.css 文件，包含了所有字体图标的 CSS 定义。你可以在项目的入口文件(如 main.js)中导入该 CSS 文件:

import "./src/assets/font/index.min.css";

之后，你就可以在 HTML 中使用字体图标了。例如，如果你有一个名为 ticon-color-pick 的图标，可以这样使用:

<span class="ticon-color-pick"></span>

查看图标列表

如果你想查看当前项目包含的所有图标，可以执行以下命令:

npx svg2font example

该命令会根据 config.json 文件生成一个静态 HTML 页面，列出了所有图标及其对应的 CSS 类名和 Unicode 编码。它还会启动一个本地服务器，方便你在浏览器中预览这个页面。

注意事项

使用 svg2font 时，需要注意以下几点:

1.SVG 文件命名: 确保 SVG 文件名不包含特殊字符或空格，否则可能会导致生成字体时出错。

2.SVG 文件优化: 在将 SVG 文件转换为字体之前，建议先对 SVG 文件进行优化，以减小文件大小。你可以使用工具如 SVGO 或 SVG Optimizer 来优化 SVG 文件。

3.字体支持:不同浏览器和操作系统对字体格式的支持程度不同。为了最大程度地兼容各种环境，svg2font 会生成多种字体格式(.eot、.ttf、.woff、.woff2 等)。

4.字体缓存: 浏览器会缓存字体文件，因此在更新字体图标时，需要确保浏览器加载了最新的字体文件。你可以在 CSS 文件中为字体文件添加版本号或时间戳，以强制浏览器重新加载字体文件。

总结

svg2font 是一个功能强大且易于使用的 SVG 图标字体生成工具。它可以帮助你轻松地将 SVG 图标转换为字体格式，并在 Web 应用程序、跨平台应用程序或图标库中使用这些字体图标。通过使用 svg2font，你可以提高页面性能、确保图标显示一致性，并享受字体图标带来的诸多优势。

无论你是 Web 开发人员、移动应用程序开发人员，还是 UI 设计师，svg2font 都值得一试。它简单易用，且具有丰富的功能和配置选项，可以满足不同项目的需求。快来试试 svg2font，让你的项目与众不同吧!

背景

去年不是降本增“笑”，“裁员”广进来着吗，公司有个项目因此停止了，最近又说这个项目还是很有必要的，就又重新启动这个项目了，然后让我这个“大聪明”把环境重新跑起来。让我无奈的是，原项目的团队成员都已经被增“笑”了，只留下了一堆不知从哪开始着手的文档。

后端还好，前端我心里就犯嘀咕了，毕竟已经5年没有关注过前端了，上次写前端代码用的还是一个基于Angular构建的移动框架inoic，不知道大家用过没有。

好在这个项目前端也用的Angular框架，本以为整个过程会很顺利，然而，结果总是事与愿违。果不其然，在搭建前端开发环境时就给我上了一课，整个过程让我抓耳挠腮，遂特此记录。

环境搭建心路历程

跟着文档操作

前端文档中对环境搭建有进行说明，一共有4个步骤，大概是这样的：

看到这里，我第一反应是“啊？现在前端这么麻烦的吗？”，我记得以前在浏览器直接打开页面就可以访问了。咱也不懂，跟着说明操作就行。

出现问题一：nodeJS版本过高

Error: error:0308010C:digital envelope routines::unsupported

......

......



{

	'opensslErrorStack': [ 'error:03000086:digital envelope routines::initialization error' ],

	'library': 'digital envelope routines',

	'reason': 'unsupported',

	'code': 'ERR_OSSL_EVP_UNSUPPORTED'

}

......

......

百度一看，原因是node 17版本之后，OpenSSL3.0对算法和密钥大小增加了严格的限制。

解决呗，降版本呗，node官网 下载了v14.12.0。

出现问题二：nodeJS版本低于Angular CLI版本

降版本之后重新运行npm start，您猜猜怎么着

Node.js version v14.12.0 detected.

The Angular CLI requires a minimum Node.js version of v18.13.



Please update your Node.js version or visit https://nodejs.org/ for additional instructions.

很明显，新老版本冲突了，又是版本问题，又是一顿百度之后，发现知乎上的一个帖子跟我这问题现象是一样的：“node是最新版，npm启动项目使用的不是最新版的node，请问这个怎么解决？”

跟着下面的评论又安装了nvm（Node Version Manager），最后一顿操作后，莫名其妙的启动了。

事后才反应过来，这个问题的根本原因是：Angular CLI是在node版本为18.3时安装的，版本更新到14.12.0后需要删除依赖重新安装。

$\color{blue}{但是我不确定的是对应的npm版本会不会一同更新，有知道的小伙伴评论区交流一下。}$

不过nvm确实好用，至少不用担心node和npm版本问题，比如下面的命令：

[xxx % ] nvm use --delete-prefix v18.13.0

Now using node v18.13.0 (npm v8.19.3)

学到的第一个知识：nvm

这里记录下nvm安装过程

配置环境变量

export NVM_DIR="$HOME/.nvm"

[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm

[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

引发的思考

技术发展日新月异

早在几年前，程序员是要前后端一起开发的，不分什么前后端，我从最开始的HTML、JavaScript开始用到AngularJS这些框架，印象最深刻的是还要解决兼容IE浏览器。没想到现在的前端也会有版本管理、组件化等等，可见技术更新迭代速度之快。

前端的重要性

当初在选择后端的时候认为前端技术无非就那些，没有什么挑战。事实上，前后端没有分离之前，市场上的应用页面也是极其简洁的，前后端一起兼顾是没有精力写出那么好看的界面和交互的。所以“前端已死”的观点我是不认可的。

降本增“笑”被迫全栈

前几天参加了开发者社区的线下聚会，聊了一下行情。有小伙伴吐槽，因为在降本增“笑”的原因，现在他们被公司要求要写前端，被迫向全栈发展，竟意外发现开发效率极其高。还有小伙伴说“前端被裁的剩下几个人，一个前端对接十个后端。”。是呀，在降本增“笑”之后，老板恨不得让一个人干十个人的活。

与时俱进

不论是几年前的前后端分离还是降本增“笑”带来的被迫全栈，还是最近“前端已死”的观点，一切都是行业发展所需要的。我们需要做到的是：不断学习和更新自己的知识和技能，以适应行业的发展和变化。

实现在cesium中基于鼠标动态绘制墙功能

1. 基本架构设计

绘制墙的交互与绘制线的交互几乎一模一样，只是一些生成wall实体的计算方法不一样，所以可以看这篇文章 cesium 鼠标动态绘制线及线动效 juejin.cn/post/728826… 了解相关的架构设计

2. 关键代码实现

2.1 绘制线交互相关事件

事件绑定相关与动态绘制线一样，这里不再重复代码

绘制形状代码有区别：
为了实现墙贴地，要实时计算minimumHeights，maximumHeights的值，min中算出地形高度，max中再地形高度的基础上再加上墙的高度

  /**

   * 绘制形状，用于内部临时画墙

   * @param positionData 位置数据

   * @param config 墙的配置项

   * @returns

   */

  private drawShape(positionData: Cartesian3[], config?: WallConfig) {

    const wallConfig = config || new WallConfig();

    const material = this.createMaterial(wallConfig);

    // @ts-ignore

    const pArray = positionData._callback();



    const shape = this.app.viewerCesium.entities.add({

      wall: {

        positions: positionData,

        material: material,

        maximumHeights: new CallbackProperty(() => {

          let heights: number[] = [];

          for (let i = 0; i < pArray.length; i++) {

            const cartographic = Cartographic.fromCartesian(pArray[i]);

            const height = cartographic.height;

            heights.push(height);

          }

          const data = Array.from(heights, (x) => x + wallConfig.height);

          return data;

        }, false),

        minimumHeights: new CallbackProperty(() => {

          let heights: number[] = [];

          for (let i = 0; i < pArray.length; i++) {

            const cartographic = Cartographic.fromCartesian(pArray[i]);

            const height = cartographic.height;

            heights.push(height);

          }

          const data = Array.from(heights);

          return data;

        }, false)

      }

    });

    return shape;

  }

2.2 创建材质相关

  /**

   * 创建材质

   * @param config 墙的配置项

   * @returns

   */

  private createMaterial(config: WallConfig) {

    let material = new ColorMaterialProperty(Color.fromCssColorString(config.style.color));

    if (config.style.particle.used) {

      material = new WallFlowMaterialProperty({

        image: config.style.particle.image,

        forward: config.style.particle.forward ? 1.0 : -1.0,

        horizontal: config.style.particle.horizontal,

        speed: config.style.particle.speed,

        repeat: new Cartesian2(config.style.particle.repeat, 1.0)

      });

    }



    return material;

  }

创建WallFlowMaterialProperty.js（具体为何如此请看这篇文章，cesium自定义材质 juejin.cn/post/728795…

import { Color, defaultValue, defined, Property, createPropertyDescriptor, Material, Event, Cartesian2 } from 'cesium';



const defaultColor = Color.TRANSPARENT;

import defaultImage from '../../../assets/images/effect/line-color-yellow.png';

const defaultForward = 1;

const defaultHorizontal = false;

const defaultSpeed = 1;

const defaultRepeat = new Cartesian2(1.0, 1.0);



class WallFlowMaterialProperty {

  constructor(options) {

    options = defaultValue(options, defaultValue.EMPTY_OBJECT);



    this._definitionChanged = new Event();

    // 定义材质变量

    this._color = undefined;

    this._colorSubscription = undefined;

    this._image = undefined;

    this._imageSubscription = undefined;

    this._forward = undefined;

    this._forwardSubscription = undefined;

    this._horizontal = undefined;

    this._horizontalSubscription = undefined;

    this._speed = undefined;

    this._speedSubscription = undefined;

    this._repeat = undefined;

    this._repeatSubscription = undefined;

    // 变量初始化

    this.color = options.color || defaultColor; //颜色

    this.image = options.image || defaultImage; //材质图片

    this.forward = options.forward || defaultForward;

    this.horizontal = options.horizontal || defaultHorizontal;

    this.speed = options.speed || defaultSpeed;

    this.repeat = options.repeat || defaultRepeat;

  }



  // 材质类型

  getType() {

    return 'WallFlow';

  }



  // 这个方法在每次渲染时被调用，result的参数会传入glsl中。

  getValue(time, result) {

    if (!defined(result)) {

      result = {};

    }



    result.color = Property.getValueOrClonedDefault(this._color, time, defaultColor, result.color);

    result.image = Property.getValueOrClonedDefault(this._image, time, defaultImage, result.image);

    result.forward = Property.getValueOrClonedDefault(this._forward, time, defaultForward, result.forward);

    result.horizontal = Property.getValueOrClonedDefault(this._horizontal, time, defaultHorizontal, result.horizontal);

    result.speed = Property.getValueOrClonedDefault(this._speed, time, defaultSpeed, result.speed);

    result.repeat = Property.getValueOrClonedDefault(this._repeat, time, defaultRepeat, result.repeat);



    return result;

  }



  equals(other) {

    return (

      this === other ||

      (other instanceof WallFlowMaterialProperty &&

        Property.equals(this._color, other._color) &&

        Property.equals(this._image, other._image) &&

        Property.equals(this._forward, other._forward) &&

        Property.equals(this._horizontal, other._horizontal) &&

        Property.equals(this._speed, other._speed) &&

        Property.equals(this._repeat, other._repeat))

    );

  }

}



Object.defineProperties(WallFlowMaterialProperty.prototype, {

  isConstant: {

    get: function get() {

      return (

        Property.isConstant(this._color) &&

        Property.isConstant(this._image) &&

        Property.isConstant(this._forward) &&

        Property.isConstant(this._horizontal) &&

        Property.isConstant(this._speed) &&

        Property.isConstant(this._repeat)

      );

    }

  },



  definitionChanged: {

    get: function get() {

      return this._definitionChanged;

    }

  },



  color: createPropertyDescriptor('color'),

  image: createPropertyDescriptor('image'),

  forward: createPropertyDescriptor('forward'),

  horizontal: createPropertyDescriptor('horizontal'),

  speed: createPropertyDescriptor('speed'),

  repeat: createPropertyDescriptor('repeat')

});



Material.WallFlowType = 'WallFlow';

Material._materialCache.addMaterial(Material.WallFlowType, {

  fabric: {

    type: Material.WallFlowType,

    uniforms: {

      // uniforms参数跟我们上面定义的参数以及getValue方法中返回的result对应，这里值是默认值

      color: defaultColor,

      image: defaultImage,

      forward: defaultForward,

      horizontal: defaultHorizontal,

      speed: defaultSpeed,

      repeat: defaultRepeat

    },

    // source编写glsl，可以使用uniforms参数，值来自getValue方法的result

    source: `czm_material czm_getMaterial(czm_materialInput materialInput)

    {

      czm_material material = czm_getDefaultMaterial(materialInput);



      vec2 st = materialInput.st;

      vec4 fragColor;

      if (horizontal) {

        fragColor = texture(image, fract(vec2(st.s - speed*czm_frameNumber*0.005*forward, st.t)*repeat));

      } else {

        fragColor = texture(image, fract(vec2(st.t - speed*czm_frameNumber*0.005*forward, st.t)*repeat));

      }



      material.emission = fragColor.rgb;

      material.alpha = fragColor.a;



      return material;

    }`

  },

  translucent: true

});



export { WallFlowMaterialProperty };

2.3 添加wall实体

  /**

   * 根据已知数据添加一个墙

   * @param config 墙的配置项

   */

  add(config: WallConfig) {

    const configCopy = cloneDeep(config);



    const positions = configCopy.positions;



    const material = this.createMaterial(configCopy);



    let distance = new DistanceDisplayCondition();

    if (configCopy.distanceDisplayCondition) {

      distance = new DistanceDisplayCondition(

        configCopy.distanceDisplayCondition.near,

        configCopy.distanceDisplayCondition.far

      );

    }



    let heights: number[] = [];

    for (let i = 0; i < positions.length; i++) {

      const cartographic = Cartographic.fromCartesian(positions[i]);

      const height = cartographic.height;

      heights.push(height);

    }



    this.app.viewerCesium.entities.add({

      id: 'wallEntity_' + configCopy.id,

      wall: {

        positions: positions,

        maximumHeights: Array.from(heights, (x) => x + configCopy.height),

        minimumHeights: Array.from(heights),

        material: material,

        distanceDisplayCondition: distance

      }

    });



    this._wallConfigList.set('wallEntity_' + configCopy.id, config);

  }

3. 业务端调用

调用方式与动态绘制线一样，是同一种架构设计，这里不再重复代码

4. 效果

前言

前端基于文件上传需要有生成临时可访问链接的能力，我们可以通过URL.createObjectURL和FileReader.readAsDataURAPI来实现。

URL.createObjectURL()

URL.createObjectURL() 静态方法会创建一个 DOMString，其中包含一个表示参数中给出的对象的URL。这个 URL 的生命周期和创建它的窗口中的 document 绑定。这个新的URL 对象表示指定的 File 对象或 Blob 对象。

1. 语法

let objectURL = URL.createObjectURL(object);

2. 参数

用于创建 URL 的 File 对象、Blob 对象或者 MediaSource 对象。

3. 返回值

一个DOMString包含了一个对象URL，该URL可用于指定源 object的内容。

4. 示例

"file" id="file">



document.querySelector('#file').onchange = function (e) {

  console.log(e.target.files[0])

  console.log(URL.createObjectURL(e.target.files[0]))

}

将上方console控制台打印的blob文件资源地址粘贴到浏览器中

blob:http://localhost:8080/1ece2bb1-b426-4261-89e8-c3bec43a4020

URL.revokeObjectURL()

在每次调用 createObjectURL() 方法时，都会创建一个新的 URL 对象，即使你已经用相同的对象作为参数创建过。当不再需要这些 URL 对象时，每个对象必须通过调用 URL.revokeObjectURL() 方法来释放。

浏览器在 document 卸载的时候，会自动释放它们，但是为了获得最佳性能和内存使用状况，你应该在安全的时机主动释放掉它们。

1. 语法

window.URL.revokeObjectURL(objectURL);

2. 参数 objectURL

一个 DOMString，表示通过调用 URL.createObjectURL() 方法返回的 URL 对象。

3. 返回值

undefined

4. 示例

"file" id="file">

<img id="img1" style="width: 200px;height: auto" />

<img id="img2" style="width: 200px;height: auto" />



document.querySelector('#file').onchange = function (e) {

	const file = e.target.files[0]

	

	const URL1 = URL.createObjectURL(file)

	console.log(URL1)

	document.querySelector('#img1').src = URL1

	URL.revokeObjectURL(URL1)

	

	const URL2 = URL.createObjectURL(file)

	console.log(URL2)

	document.querySelector('#img2').src = URL2

}

与FileReader.readAsDataURL(file)区别

1. 主要区别

• 通过FileReader.readAsDataURL(file)可以获取一段data:base64的字符串


• 通过URL.createObjectURL(blob)可以获取当前文件的一个内存URL

2. 执行时机

• createObjectURL是同步执行（立即的）


• FileReader.readAsDataURL是异步执行（过一段时间）

3. 内存使用

• createObjectURL返回一段带hash的url，并且一直存储在内存中，直到document触发了unload事件（例如：document close）或者执行revokeObjectURL来释放。


• FileReader.readAsDataURL则返回包含很多字符的base64，并会比blob url消耗更多内存，但是在不用的时候会自动从内存中清除（通过垃圾回收机制）

4. 优劣对比

• 使用createObjectURL可以节省性能并更快速，只不过需要在不使用的情况下手动释放内存


• 如果不在意设备性能问题，并想获取图片的base64，则推荐使用FileReader.readAsDataURL

前言

大家好，我是林三心，用最通俗易懂的话讲最难的知识点是我的座右铭，基础是进阶的前提是我的初心~

有趣的动画效果

前几天在网上看到了一个很有趣的动画效果，如下，光会跟随鼠标在卡片上进行移动，并且卡片会有视差的效果

那么在 Vue3 中应该如何去实现这个效果呢？

基本实现思路

其实实现思路很简单，无非就是分几步：

• 首先，卡片是相对定位，光是绝对定位


• 监听卡片的鼠标移入事件mouseenter，当鼠标进入时显示光


• 监听卡片的鼠标移动事件mouseover，鼠标移动时修改光的left、top，让光跟随鼠标移动


• 监听卡片的鼠标移出事件mouseleave，鼠标移出时，隐藏光

我们先在 Index.vue 中准备一个卡片页面，光的CSS效果可以使用filter: blur() 来实现

可以看到现在的效果是这样

实现光源跟随鼠标

在实现之前我们需要注意几点：

• 1、鼠标移入时需要设置卡片 overflow: hidden，否则光会溢出，而鼠标移出时记得还原


• 2、获取鼠标坐标时需要用clientX/Y而不是pageX/Y，因为前者会把页面滚动距离也算进去，比较严谨

刚刚说到实现思路时我们说到了mouseenter、mousemove、mouseleave，其实mouseenter、mouseleave 这二者的逻辑比较简单，重点是 mouseover 这个监听函数

而在 mouseover 这个函数中，最重要的逻辑就是：光怎么跟随鼠标移动呢？

或者也可以这么说：怎么计算光相对于卡片盒子的 left 和 top

对此我专门画了一张图，相信大家一看就懂怎么算了

• left = clientX - x - width/2


• height = clientY - y - height/2

知道了怎么计算，那么逻辑的实现也很明了了~封装一个use-light-card.ts

接着在页面中去使用

这样就能实现基本的效果啦~

卡片视差效果

卡片的视差效果需要用到样式中 transform 样式，主要是配置四个东西：

• perspective：定义元素在 3D 变换时的透视效果


• rotateX：X 轴旋转角度


• rotateY：Y 轴旋转角度


• scale3d：X/Y/Z 轴上的缩放比例

现在就有了卡片视差的效果啦~

给所有卡片添加光源

上面只是给一个卡片增加光源，接下来可以给每一个卡片都增加光源啦！！！

让光源变成可配置

上面的代码，总感觉这个 hooks 耦合度太高不太通用，所以我们可以让光源变成可配置化，这样每个卡片就可以展示不同大小、颜色的光源了~像下面一样

既然是配置化，那我们希望是这么去使用 hooks 的，我们并不需要自己在页面中去写光源的dom节点，也不需要自己去写光源的样式，而是通过配置传入 hooks 中

所以 hooks 内部要自己通过操作 DOM 的方式，去添加、删除光源，可以使用createElement、appendChild、removeChild 去做这些事~

完整源码

<!-- Index.vue -->



<template>

  <div class="container">

    <!-- 方块盒子 -->

    <div class="item" ref="cardRef1"></div>

    <!-- 方块盒子 -->

    <div class="item" ref="cardRef2"></div>

    <!-- 方块盒子 -->

    <div class="item" ref="cardRef3"></div>

  </div>

</template>



<script setup lang="ts">

import { useLightCard } from './use-light-card';



const { cardRef: cardRef1 } = useLightCard();

const { cardRef: cardRef2 } = useLightCard({

  light: {

    color: '#ffffff',

    width: 100,

  },

});

const { cardRef: cardRef3 } = useLightCard({

  light: {

    color: 'yellow',

  },

});

</script>



<style scoped lang="less">

.container {

  background: black;

  width: 100%;

  height: 100%;

  padding: 200px;

  display: flex;

  justify-content: space-between;



  .item {

    position: relative;

    width: 125px;

    height: 125px;

    background: #1c1c1f;

    border: 1px solid rgba(255, 255, 255, 0.1);

  }

}

</style>

// use-light-card.ts



import { onMounted, onUnmounted, ref } from 'vue';



interface IOptions {

  light?: {

    width?: number; // 宽

    height?: number; // 高

    color?: string; // 颜色

    blur?: number; // filter: blur()

  };

}



export const useLightCard = (option: IOptions = {}) => {

  // 获取卡片的dom节点

  const cardRef = ref<HTMLDivElement | null>(null);

  let cardOverflow = '';

  // 光的dom节点

  const lightRef = ref<HTMLDivElement>(document.createElement('div'));

  // 设置光源的样式



  const setLightStyle = () => {

    const { width = 60, height = 60, color = '#ff4132', blur = 40 } = option.light ?? {};

    const lightDom = lightRef.value;

    lightDom.style.position = 'absolute';

    lightDom.style.width = `${width}px`;

    lightDom.style.height = `${height}px`;

    lightDom.style.background = color;

    lightDom.style.filter = `blur(${blur}px)`;

  };



  // 设置卡片的 overflow 为 hidden

  const setCardOverflowHidden = () => {

    const cardDom = cardRef.value;

    if (cardDom) {

      cardOverflow = cardDom.style.overflow;

      cardDom.style.overflow = 'hidden';

    }

  };

  // 还原卡片的 overflow

  const restoreCardOverflow = () => {

    const cardDom = cardRef.value;

    if (cardDom) {

      cardDom.style.overflow = cardOverflow;

    }

  };



  // 往卡片添加光源

  const addLight = () => {

    const cardDom = cardRef.value;

    if (cardDom) {

      cardDom.appendChild(lightRef.value);

    }

  };

  // 删除光源

  const removeLight = () => {

    const cardDom = cardRef.value;

    if (cardDom) {

      cardDom.removeChild(lightRef.value);

    }

  };



  // 监听卡片的鼠标移入

  const onMouseEnter = () => {

    // 添加光源

    addLight();

    setCardOverflowHidden();

  };



  // use-light-card.ts



  // 监听卡片的鼠标移动

  const onMouseMove = (e: MouseEvent) => {

    // 获取鼠标的坐标

    const { clientX, clientY } = e;

    // 让光跟随鼠标

    const cardDom = cardRef.value;

    const lightDom = lightRef.value;

    if (cardDom) {

      // 获取卡片相对于窗口的x和y坐标

      const { x, y } = cardDom.getBoundingClientRect();

      // 获取光的宽高

      const { width, height } = lightDom.getBoundingClientRect();

      lightDom.style.left = `${clientX - x - width / 2}px`;

      lightDom.style.top = `${clientY - y - height / 2}px`;



      //   设置动画效果

      const maxXRotation = 10; // X 轴旋转角度

      const maxYRotation = 10; // Y 轴旋转角度



      const rangeX = 200 / 2; // X 轴旋转的范围

      const rangeY = 200 / 2; // Y 轴旋转的范围



      const rotateX = ((clientX - x - rangeY) / rangeY) * maxXRotation; // 根据鼠标在 Y 轴上的位置计算绕 X 轴的旋转角度

      const rotateY = -1 * ((clientY - y - rangeX) / rangeX) * maxYRotation; // 根据鼠标在 X 轴上的位置计算绕 Y 轴的旋转角度



      cardDom.style.transform = `perspective(1000px) rotateX(${rotateX}deg) rotateY(${rotateY}deg)`; //设置 3D 透视

    }

  };

  // 监听卡片鼠标移出

  const onMouseLeave = () => {

    // 鼠标离开移出光源

    removeLight();

    restoreCardOverflow();

  };



  onMounted(() => {

    // 设置光源样式

    setLightStyle();

    // 绑定事件

    cardRef.value?.addEventListener('mouseenter', onMouseEnter);

    cardRef.value?.addEventListener('mousemove', onMouseMove);

    cardRef.value?.addEventListener('mouseleave', onMouseLeave);

  });



  onUnmounted(() => {

    // 解绑事件

    cardRef.value?.removeEventListener('mouseenter', onMouseEnter);

    cardRef.value?.removeEventListener('mousemove', onMouseMove);

    cardRef.value?.removeEventListener('mouseleave', onMouseLeave);

  });



  return {

    cardRef,

  };

};

结语 & 加学习群 & 摸鱼群

我是林三心

• 一个待过小型toG型外包公司、大型外包公司、小公司、潜力型创业公司、大公司的作死型前端选手；


• 一个偏前端的全干工程师；


• 一个不正经的掘金作者；


• 一个逗比的B站up主；


• 一个不帅的小红书博主；


• 一个喜欢打铁的篮球菜鸟；


• 一个喜欢历史的乏味少年；


• 一个喜欢rap的五音不全弱鸡

如果你想一起学习前端，一起摸鱼，一起研究简历优化，一起研究面试进步，一起交流历史音乐篮球rap，可以来俺的摸鱼学习群哈哈，点这个，有7000多名前端小伙伴在等着一起学习哦 --> 摸鱼沸点

hi~好久不见，距离上次发文隔了有段时间了，这段时间，我是裸辞去感受了一下前端市场的水深火热，那么这次咱们不聊技术，就说一说最近这段时间的经历和一些感触吧。

先说一下自己的个人情况，目前做前端四年，双非本，非科班，技术栈Vue和小程序，读过源码，刷过算法，写过开源，工作地点在武汉。

我是在三月初裸辞向公司提的离职，并在四月初离开。在做出裸辞这个决定之前，其实也是犹豫了好久，因为在上家公司做开发还是很愉快的，同时看网上大家对于如今的市场行情评价都是寒气逼人，所以对于这次的裸辞我思考了有半年之久。

我的想法有几个点：

综合考虑了以上几点，决定就勇敢一次，迈出这一步，不论后面的结果如何都是自己的选择。

面试

然后，就聊一聊最近这段时间面试的感触吧。先说结论，别的城市倒不清楚，就只说武汉，行情的确是有些差的，主要体现在小公司开不起价，大点公司（武汉其实也没什么大公司）又很难过简历筛，再加之岗位有限，所以整体的感受就是水深火热。

从三月中下旬开始投递简历，一直到五月底决定去向，这期间在招聘软件上打了上百次招呼，拿到十二个面试机会，通过的有七家，最终选择了离家还算比较近，工作流程以及规模还不错的一家公司入了职。

这段时间可以说是要比平时上班还要累的，工作日每天起来就会去刷一刷招聘软件，去看看有没有新出的职位可以聊一下的，但渐渐的就会发现，招聘软件翻来覆去就那么几家公司，还都是常年招聘的，新出的机会可能要好久才会遇到一次。

能约到面试的几天心态还会好一些，可一旦连续几天没有约到面试，投递简历都石沉大海，那个时候内心就会开始有些焦虑，很容易会想要不要随便找一家将就下得了，但好在每次有这种想法的时候，都会有新的面试邀约出现，也算是挺幸运的了。而且根据每次面试的过程来看，目前我点的技能点是完全够用了的，甚至面一些小公司的时候，有时能清晰的感受到在吊打面试官，这也算是无形中增加了我的信心吧，能够让我继续战斗下去~ 而且也非常感谢在找工作时给我鼓励的掘友，当时面了一家公司，而面试官是一位掘友的朋友，可能下去后面试官和掘友提起了我的面试，晚上在掘金收到了掘友的私信，说我的技术一定没问题的，而且算法可以，一定要去投一投大公司~ 当天收到私信时，可以说真的是热泪盈眶，感受到了寒冬中的小小温暖，真的非常感谢~

然后说一下面试体验吧，面试体验真的和公司规模成正比的。

窒息的面试体验

我面的这几家，有一些小公司的面试官或者hr真的各种作妖：

• 有的时候吊打了面试官，然后hr来谈薪想压价，拿什么压我都能理解，毕竟公司给到hr的预算可能有限，但是拿技术来压，真就不理解，面试官都没说什么，甚至当场说技术确实很不错，然后一个hr来尝试根据之前做的项目找漏洞去聊技术，聊复杂度去压价，真的是让人难以理解。


• 有的公司则是非常的小，然后面试官应该就是公司领导吧，给了一份笔试题，做完后去面试，笔试当时做了15分钟，面试只12分钟，而面试的时候在刚进行2分钟我就已经想结束面试直接走人了，面试官就是对着他出的一份稀烂的笔试题一个个问，我也一个个给他答，每答一个他都先把你的答案给否定，然后尝试从回答中找漏洞，没有找到那就再问一个他自己现编的很奇怪的问题，真就离谱，也真是我素质还算好，没有当场去怼他，当时面的12分钟真的是折磨。


• 再不然有些面试官，就是简历也不细看，就会去问一些冷门API的用法，这一家当时我已经面到后期了，见了形形色色的面试官，所以也不惯着，直接就问他，你问这个有什么用呢？你是想招干活的人，还是想招可培养的人？那你面试问一个API能问出来什么呢？

愉快的面试体验

说完了小公司的体验，再说一些体验还不错的面试吧，一个体验比较好的面试给人的感觉就是，对方是能把我掌握的技术深度和广度都给探到，并且双方面试过程更像是探讨的过程。

• 有的面试官会在听你介绍项目难点以及解决方案的时候，逐步的引导你去思考出更优的解决方案。


• 有的面试官则会给你一种感觉就是，这个面试官真的很大佬，比如我遇到的一个面试官精通源码，虽然我也看过并且写过源码文章，但在很多细节的地方还是会有所遗忘，在面试的过程中，有的地方思路乱了，面试官则会在我把我知道的都讲完之后，去完整的给梳理一次思路，并说明整个的运行流程。

这两种面试官其实都有一个共同的点，就是他是在找你技术的深度和解决问题的能力，让你尽可能的展示自己，而不是对着一份面试题或者就是想刁难你找优越感。

最后的选择

最终，选择的这家，其实薪资上的涨幅很小，但工作强度会比上一家大上不少。面了2个月，这个过程很累，我也没有太多的能量去接着去面试了，而这家公司整体面试体验给我的感觉还可以，就先入职看看喽~

然后，关于自己的职业发展，目前其实是有些迷茫的，刚入行前端的时候，感觉当时的机会还是很多的，能看到很多大厂的招聘要求以及结合一些在网上看到的一些大佬的经历，然后我就做出了规划：去研究源码和算法，参与一些开源，当工作经验够3年之后，去尝试投递一下大厂，看一看新的机会。可是现在，当经验，技能可以达到要求之后，市场却凉下来了，不是92的学历或者大厂的履历，连简历筛都很难过的去，小一点的公司也想用较低的工资去招一个经验丰富的人，然后面试就还会问对加班的看法，甚至有的还会问无效加班接不接受，感觉整个市场都是一个让人无法理解的样子。

最后

上面聊了这么多，不管怎样，也确实是当前武汉前端求职环境的现状（大佬当然无所畏惧），所以，如果有朋友还跃跃欲试想换个环境，那我建议也是，如果可以的话找好再走，不要着急（但这个问题的点就在于，很多公司会要求线下面试，就算线上面试，时间安排其实也会很不方便），可以投递一下先试试水，感受一下市场。但如果是有自己的规划或者实在是想要换个环境的朋友，可以根据我上面说的，只要能做好心理预期（可能会连续打招呼两三天，甚至一周都没有回应），确保自己的心态稳定（因为这本来就不是个人的问题，我们能做的就是把所掌握的技术准备充分就可以了），其实也可以一试，机会是有的，但是不多，需要自己去争取，并把握住。

最后的最后，关于起这个标题，其实是我在一开始写这篇文章的时候脑海中就浮现的宫崎骏的这个电影和这句话。。。关于这个电影，网上有很多的评价，有的人会觉得这个电影不知道到底想说些什么，教会我们些什么。那有没有可能，老爷子其实也没打算教我们什么，当下的环境已经塞给我们太多东西，可以单纯的感受一下宫崎骏为我们创造的奇幻世界也是挺好的~ 你想活出怎样的人生其实都没有问题，或奋斗，或躺平，或去大城市，或留在小城市都只是一个选择,一种体验而已，没什么对错之分。所以这句话是在问掘友，也是在问我自己吧~

后续的个人规划，其实我也还没有很明确，现阶段，打算先继续搞一搞自己感兴趣的技术吧，不管环境怎样，个人的状态怎样，只要是在向前的，我想总归是好的吧，后续也会继续输出一些有意思的内容，掘友们共勉~

本文是azuo和萌妹俩技术创作之旅的第15篇原创文章，内容创作@azuo😄，精神支持@大头萌妹😂

前言：本文主要探讨了移动混合开发（ Hybrid APP） 开发的技术演进历程，将阐述了webview（H5）、React Native、小程序技术等在其中所扮演的关键角色及带来的变革。原生能力缺失、长时间白屏、用户操作响应不及时等web开发的问题是如何被解决的？

一、诞生背景

早期移动应用开发，由于机器硬件性能的方面影响，为了更好的用户体验（操作响应、流畅度和原生的能力），主要集中在原生应用开发上。

1.1 原生开发的缺点

原生应用开发周期和更新周期长，也逐渐在快速的迭代的互联网产品产生矛盾。

缺点：

• 开发周期长：开发调试需要编译打包，动辄就需要几分钟甚至十几分钟，相比H5的亚秒级别的热更能力，是在太长了；


• 更新周期长：正常的发版需要用户手动更新，无法做到H5这种发布即更新的效率。


• 使用前需要安装；


• 需要多端开发；（Android和iOS两端开发人力成本高）