URL 结尾是否带 / 主要影响的是 服务器如何解析请求 以及 相对路径的解析方式，具体区别如下：

1. 基础概念

• URL（统一资源定位符） ：用于唯一标识互联网资源，如网页、图片、API等。


• 目录 vs. 资源：
  
  
  
  
  • 以 / 结尾的 URL 通常表示目录，例如：
    
    

    https://example.com/folder/
    
    

    
    
  
  
  • 不以 / 结尾的 URL 通常指向具体的资源（如文件），例如：
    
    

    https://example.com/file
    
    

    
    
  
  
  
  

2. 带 / 和不带 / 的具体区别

（1）目录 vs. 资源

• https://example.com/folder/
  
  
  
  
  • 服务器通常会将其解析为 目录，并尝试返回该目录下的默认文件（如 index.html）。
  
  
  
  


• https://example.com/folder
  
  
  
  
  • 服务器可能会将其视为 文件，如果 folder 不是文件，而是目录，服务器可能会返回 301 重定向到 folder/。
  
  
  
  

📌 示例：

• 访问 https://example.com/blog/
  
  
  
  
  • 服务器可能返回 https://example.com/blog/index.html。
  
  
  
  


• 访问 https://example.com/blog（如果 blog 是个目录）
  
  
  
  
  • 服务器可能重定向到 https://example.com/blog/，再返回 index.html。
  
  
  
  

（2）相对路径解析

URL 末尾是否有 / 会影响相对路径的解析。

假设 HTML 页面包含以下 <img> 标签：

<img src="image.png">

📌 示例：

• 访问 https://example.com/folder/
  
  
  
  
  • 图片路径解析为 https://example.com/folder/image.png
  
  
  
  


• 访问 https://example.com/folder
  
  
  
  
  • 图片路径解析为 https://example.com/image.png
  
  
  • 可能导致 404 错误，因为 image.png 在 folder/ 里，而浏览器错误地去 example.com/ 下查找。
  
  
  
  

原因：

• 以 / 结尾的 URL，浏览器会认为它是一个目录，相对路径会基于 folder/ 解析。


• 不带 /，浏览器可能认为 folder 是文件，相对路径解析可能会出现错误。

（3）SEO 影响

搜索引擎对 https://example.com/folder/ 和 https://example.com/folder 可能会视为两个不同的页面，导致 重复内容问题，影响 SEO 排名。因此：

• 网站通常会选择 一种形式 并用 301 重定向 规范化 URL。


• 例如：
  
  
  
  
  • https://example.com/folder 自动跳转 到 https://example.com/folder/。
  
  
  • 反之亦然。
  
  
  
  

（4）API 请求

对于 RESTful API，带 / 和不带 / 可能导致不同的行为：

• https://api.example.com/users
  
  
  
  
  • 可能返回所有用户数据。
  
  
  
  


• https://api.example.com/users/
  
  
  
  
  • 可能返回 404 或者产生不同的结果（取决于服务器实现）。
  
  
  
  

一些 API 服务器对 / 非常敏感，因此最好遵循 API 文档的规范。

3. 总结

如果你在开发网站，建议：

我是天元，立志做1000个有趣的项目的前端。如果你喜欢的话，请点赞，收藏，转发。评论领取零花钱+100勋章

背景

我老婆从事HR的工作，公司有很多连锁店，她需要将所有的门店的工资汇总计算，然后再拆分给各门店请确认，最后再提供给财务发工资。

随着门店数量渐渐增多，渐渐的我老婆已经不堪重负，每天加班都做不完，严重影响夫妻感情生活。

最终花费了2天的时间，完成了整个node程序，她只需要传入工资表，相应的各种表格在10s内自动输出。目前已正式交付，得到了每月零花钱提高100元的重大成果。

整体需求

• 表格的导入和识别


• 表格的计算（计算公式要代入），表格样式正确


• 最终结果按照门店拆分为工资表

需求示例（删减版）

需求为，根据传入的基本工资及补发补扣，生成总工资表，门店工资表，财务工资表发放表。

工资表中字段为门店，姓名，基本工资，补发补扣，最终工资（基本工资+补发补扣）。最后一行为总计

门店工资表按照每个门店，单独一个表格，字段同工资表。最后一行为总计

工资表

基础工资

补发补扣

技术选型

这次的主力库为exceljs，官方文档介绍如下

读取，操作并写入电子表格数据和样式到 XLSX 和 JSON 文件。

一个 Excel 电子表格文件逆向工程项目

选择exceljs是因为它支持完整的excel的样式及公式。

安装及目录结构

优先安装exceljs

npm init

yarn add exceljs

创建input,out,src三个文件夹，src放入index.js

package.json增加start脚本

"scripts": {

    "start": "node src/index.js"

  },

代码相关

导入

通过new Excel.Workbook();创建一个工作簿，通过workbook.xlsx.readFile来导入文件, 注意这是个promise

const ExcelJS = require("exceljs");

const path = require("path");

const inputPath = path.resolve(__dirname, "../input");

const outputPath = path.resolve(__dirname, "../out");



const loadInput =async () => {

  const workbook = new ExcelJS.Workbook();

  const inputFile = await workbook.xlsx.readFile(inputPath + "/工资表.xlsx")

};



loadInput()

数据拆分

通过getWorksheetApi,我们可以获取到对应的工作表的内容

  const loadInput =async () => {

	...

  // 基本工资

  const baseSalarySheet = inputFile.getWorksheet("基本工资");

  // 补发补扣

  const supplementSheet = inputFile.getWorksheet("补发补扣");



}

然后我们需要进一步的来进行拆分，因为第一行为每个工作表的头，这部分在我们实际数据处理中不会使用，所以通过getRows来获取实际的内容。

  const baseSalaryContent = baseSalarySheet.getRows(

    2,

    baseSalarySheet.rowCount

  );

  baseSalaryContent.map((row) => {

    console.log(row.values);

  });



  /**

[ <1 empty item>, '2024-02', '海贼王', '路飞', 12000 ]

[ <1 empty item>, '2024-02', '海贼王', '山治', 8000 ]

[ <1 empty item>, '2024-02', '火影忍者', '鸣人', '6000' ]

[ <1 empty item>, '2024-02', '火影忍者', '佐助', 7000 ]

[ <1 empty item>, '2024-02', '火影忍者', '雏田', 5000 ]

[ <1 empty item>, '2024-02', '一拳超人', '琦玉', 4000 ]

[]

[]

**/

可以看到实际的内容已经拿到了，我们要根据这些内容拼装一下最终便于后续的调用。

我们可以通过 row.getCellApi获取到对应某一列的内容，例如门店是在B列，那么我们就可以使用row.getCell('B')来获取。

因为我们需要拆分门店，所以这里的基本工资，我们以门店为单位，把数据进行拆分

  const baseSalary = {};



  baseSalaryContent.forEach((row) => {

    const shopName = row.getCell("B").value;

    if (!shopName) return; // 过滤空行



    const name = row.getCell("C").value;

    const salary = row.getCell("D").value;



    if (!baseSalary[shopName]) {

      baseSalary[shopName] = [];

    }

    baseSalary[shopName].push({

      name,

      salary,

    });

  });

这样我们得到了一个以门店名称为key的对象，value为该门店的员工信息数组。利用相同方法，获取补发补扣。因为每个人已经确定了门店，所以后续只需要根据姓名来做key，拆分成一个object即可

  // 补发补扣

  const supplement = {};

  supplementSheet.getRows(2, supplementSheet.rowCount).forEach((row) => {

    const name = row.getCell("C").value;

    const type = row.getCell("H").value;



    let count = row.getCell("D").value;

    // 如果为补扣，则金额为负数

    if (type === "补扣") {

      count = -count; 

    }

    if (!supplement[name]) {

      supplement[name] = 0;

    }

    supplement[name] += count;

  });



  

数据组合

门店工资表

因为每个门店需要独立一张表，所以需要遍历baseSalary

  

  Object.keys(baseSalary).forEach((shopName) => {

    const workbook = new ExcelJS.Workbook();

    const worksheet = workbook.addWorksheet("工资表");



    // 添加表头

    worksheet.addRow([

      "序号",

      "门店",

      "姓名",

      "基本工资",

      "补发补扣",

      "最终工资",

    ]);

    baseSalary[shopName].forEach((employee, index) => {

      worksheet.addRow([

        index + 1,

        shopName,

        employee.name,

        +employee.salary,

        supplement[employee.name] || 0,

        +employee.salary + (supplement[employee.name] || 0),

      ]);

    });

  });

此时你也可以快进到表格输出来查看输出的结果，以便随时调整

这样我们就把基本工资已经写入工作表了，但是这里存在问题，最终工资使用的是一个数值，而没有公式。所以我们需要改动下

 worksheet.addRow([        index + 1,        shopName,        employee.name,        employee.salary,        supplement[employee.name] || 0,

        {

          formula: `D${index + 2}+E${index + 2}`,

          result: employee.salary + (supplement[employee.name] || 0),

        },

      ]);

这里的formula将对应到公式，而result是显示的值，这个值是必须写入的，如果你写入了错误的值，会在表格中显示该值，但是双击后，公式重新计算，会替换为新的值。所以这里必须计算正确

合计

依照上方的逻辑，继续添加一行作为合计，但是之前计算的时候，需要添加一个临时变量，记录下合计的相关内容。

     const count = [0, 0, 0];

    baseSalary[shopName].forEach((employee, index) => {

      count[0] += +employee.salary;

      count[1] += supplement[employee.name] || 0;

      count[2] += +employee.salary + (supplement[employee.name] || 0);

      worksheet.addRow([

        index + 1,

        shopName,

        employee.name,

        +employee.salary,

        supplement[employee.name] || 0,

        {

          formula: `D${index + 2}+E${index + 2}`,

          result: +employee.salary + (supplement[employee.name] || 0),

        },

      ]);

    });

然后在尾部添加一行

worksheet.addRow([      "合计",      "",      "",      {        formula: `SUM(D2:D${baseSalary[shopName].length + 1})`,

        result: count[0],

      },

      {

        formula: `SUM(E2:E${baseSalary[shopName].length + 1})`,

        result: count[1],

      },

      {

        formula: `SUM(F2:F${baseSalary[shopName].length + 1})`,

        result: count[2],

      },

    ]);

美化

表格的合并，可以使用mergeCells

   worksheet.mergeCells(

      `A${baseSalary[shopName].length + 2}:C${baseSalary[shopName].length + 2}`

    );

这样就合并了我们的最后一行的前三列，接下来我们要给表格添加线条。

对于批量的添加，可以直接使用addConditionalFormatting，它将在一个符合条件的单元格范围内添加规则

    worksheet.addConditionalFormatting({

      ref: `A1:F${baseSalary[shopName].length + 2}`,

      rules: [

        {

          type: "expression",

          formulae: ["true"],

          style: {

            border: {

              top: { style: "thin" },

              left: { style: "thin" },

              bottom: { style: "thin" },

              right: { style: "thin" },

            },

            alignment: { vertical: "top", horizontal: "left", wrapText: true },

          },

        },

      ],

    });

表格输出

现在门店工资表已经拆分完成，我们可以直接保存了，使用xlsx.writeFileApi来保存文件

 Object.keys(baseSalary).forEach((shopName) => {

 

	...



	  workbook.xlsx.writeFile(outputPath + `/${shopName}工资表.xlsx`);

})

最终效果

相关代码地址

github.com/tinlee/1000…

前言

autofit.js 发布马上要一年了，也收获了一批力挺用户，截至目前它在github上有1k 的 star，npm 上有超过 13k 的下载量。

这篇文章主要讲从设计稿到落地开发大屏应用，大道至简，这篇文章能帮助各位潇洒自如的开发大屏。

分析设计稿

分析设计稿之前先吐槽一下大屏这种展现形式，这简直就是自欺欺人、面子工程的最直接的诠释，是吊用没有，只为了好看，如果设计的再不好看啊，这就纯纯是屎。在我的理解中，这就像把PPT放到了web端，仅此而已。

但是王哥告诉我："你看似没有用的东西，其实都有用，很多想真正做出有用的产品的企业，没钱，就要先把面子工程做好，告诉别人他们要做一件什么事，这样投资人才会看到，后面才有机会发展。"

布局方案

上图展示了一个传统意义上且比较普遍的大屏形态，分为四个部分，分别是

头部

头部经常放标题、功能菜单、时间、天气

左右面板

左右面板承载了各种数字和报表，还有视频、轮播图等等

中间

中间部分一般放地图，这其中又分假地图（一张图片）、图表地图（如echarts）、地图引擎（如：leaflet、mapbox、高德、百度）。或者有的还会放3D场景，一般有专门的同事去做3D场景，然后导入到web端。

大屏的设计通常的分辨率是 1920*1080 的，这也是迄今为止应用最广泛的显示器配置，当然也有基于客户屏幕做的异形分辨率，这就五花八门了。

但是万变不离其宗，分辨率的变化不会影响它的基本结构，根据上面的图，我们可以快速构建结构代码

  <div class='Box'>

    <div class="header"></div>

    <div class="body">

      <div class="leftPanel"></div>

      <div class="mainMap"></div>

      <div class="rightPanel"></div>

    </div>

  </div>

上面的代码实现了最简单的上下(Box)+左右(body)的布局结构，完全不需要任何定位策略。

要实现上图的效果，只需最简单的CSS即可完成布局。

组件方案

大屏虽然是屎，但是是一种可玩性很强的项目，想的越复杂，做起来就越复杂，想的越简单，做起来就越简单。

可以疯狂封装炫技，因为大屏里面的可玩组件简直太多了，且涵盖的太全了，想怎么玩都可以，包括但不限于 各类图表库的封装（echarts、highCharts、vChart）、轮播图（swiper）、地图引擎、视频库（包括直播流）等等。

如果想简单，甚至可以不用封装，可以看到结构甚至简单到不用CSS几行就可以搭建出基本框架，只把header、leaftPanel、rightPanel、map封装一下就可以了。

这里还有一个误区，就是大家都喜欢把 大型的组件库 拉到大屏里来用，结果做完了发现好像只用了一个 toast 和一个下拉组件，项目打包后却增大了几十倍的体积，其实像这种简单的组件，完全可以手写，或者找小的独立包来用，一方面会减小体积，不至于让项目臃肿，另一方面可以锻炼自己的手写能力，这才是有必要的封装。

适配

目前主流的适配方案，依然是 rem 方案，其原理就是根据根元素的 font-size 自动计算大小，但是此方法需要手动计算 rem 值，或者使用第三方插件如postcss等，但是此方案还有一个弊端，就是无法向下兼容，因为浏览器中最小的文字大小是12px。

vh/vw方案就不再赘述了，原理基本和 rem/em 相似，都涉及到单位的转换。

autofit.js

主要讲一下使用 autofit.js 如何快速实现适配。

不支持的场景

首先 autofit.js 不支持 elementUI(plus)、ant-design等组件库，具体是不支持包含popper.js的组件，popper.js 在计算弹出层位置时，不会考虑 scale 后的元素的视觉大小，所以会造成弹出元素的位置偏移。

其次，不支持 百度地图，百度地图对窗口缩放事件没有任何处理，有同学反馈说，即使使用了resize属性，百度地图在和autofit.js共同使用时，也会有事件热区偏移的问题。而且百度地图使用 bd-09 坐标系，和其他图商不通用，引擎的性能方面也差点意思，个人不推荐在开发中使用百度地图。

然后一些拖拽库，如甘特图插件，可能也不支持，他们在计算鼠标位置时同样没有考虑 scale 后的元素的视觉大小。

用什么单位

不支持的单位：vh、vw、rem、em

让我诧异的是，老有人问我该用什么单位，主要徘徊在 px 和 % 之间，加群的同学多数是因为用了相对单位，导致留白了。不过人各有所长，跟着各位大佬我也学到了很多。

看下图

假如有两个宽度为1000的元素，他们内部都有一个子元素，第一个用百分比设置为 width:50%;left:1% , 第二个设置为 wdith:500px;left:10px 。此时，只要外部的1000px的容器宽度不变，这两个内部元素在视觉上是一模一样的，且在实际数值上也是一模一样的，他们宽度都为500px，距离左侧10px。

但是如果外部容器变大了，来看一下效果：

在样式不变的情况下，仅改变外部容器大小，差异就出来了，由上图可知，50%的元素依然占父元素的一半，实际宽度变成了 1000px，距离左侧的实际距离变成了 20px。

这当然不难理解，百分比单位是根据 最近的、有确定大小的父级元素计算的。

所以，应该用什么单位其实取决于想做什么，举个例子：在1920*1080基础上开发，中间的地图写成了宽度为 500px ，这在正常情况下，看起来没有任何问题，它大概占屏幕的 26%，当屏幕分辨率达到4096*2160时,它在屏幕上只占 12%，看起来就是缩在一角。而当你设置宽度为26%时，无论显示器如何变化，它始终占屏幕26%。

autofit.js 所干的事，就是把1000px 变成了 2000px或者把2000px变成了1000px，并给它设置了一个合适的缩放大小。

图表、图片拉伸

背景或各种图片按需设置 object-fit: cover;即可

图表如echarts一般推荐使用百分比，且监听窗口变化事件做resize()

结语

再次感慨，大道至简，事情往往没有那么复杂，祝各位前程似锦。

迅速崛起和快速退出

时间回到2014年，此时的 Angular 1.x 习得了多种武林秘籍，左手降龙十八掌、右手六脉神剑，哦不，左手双向数据绑定、右手依赖注入、上能模块化开发、下有模板引擎 和 前端路由, 背后还有Google这个风头无两的带头大哥做技术背书，可以说集万千功能和宠爱于一身，妥妥的主角光环。

而此时的江湖，B端开发正尝到了 SPA 的甜头，积极的从传统的 MVC 开发模式转变为更为方便快捷的单页面应用开发模式，

文章同步在公众号：萌萌哒草头将军，欢迎关注！

一拍即合，强大的一站式单页面开发框架Angular自然而然，就成了公认的武林盟主，江湖一哥。

但是好景不长，2016年9月14日 Angular 2.x 的发布，彻底断送了武林盟主的宝座，

Vue：大哥，你可是真给机会呀！

2.0 使用ts彻底重写（最早支持ts的框架）、放弃了脏检查更新机制，引入了响应式系统、使用现代浏览器标准、加入装饰器语法，和 1.0 完全不兼容。可以从上图看到，此时大家基本上还不太接受ts!

新手面对陡然升高的学习曲线叫苦连连，已经入坑的开发者因为巨大的迁移工作而怨声载道。

此时，默默耕耘了两年的小弟，Vue已经拥有完备的本地化文档和丰富的可选生态，而且作为新手你只要会使用html、css、javascript，就可以上手写项目了。

所以，此时的 Vue 振臂一呼：“王侯将相宁有种乎！”，立马新皇加冕！

积极改变，三拜义父的数据驱动

忆往昔峥嵘岁月稠，恰同学少年，风华正茂；书生意气，挥斥方遒。

一转眼，angular 已经发布第19个大版本了（平均一年两个版本）。

失去武林盟主的Angular，飘零半生，未逢明主，公若不弃，Angular愿拜为义父，

从 脏检查机制 到 响应式系统，再到Signals系统， Angular 历经沧桑的数据驱动方式可以说是前端发展的缩影。

脏检查机制

脏检查机制 是通过拦截异步操作，http setTimeout 用户交互事件等，触发变更检测系统，从根组件开始检查组件中数据是否有更新，有更新时，对应的 $scope 变量会被标记为 脏，然后同步的更新dom的内容，重新开始变更检查，直到稳定后标记为干净，即通过稳定性检查！

<!DOCTYPE html>

<html lang="en" ng-app="myApp">

<head>

    <meta charset="UTF-8">

    <title>AngularJS Counter</title>

    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.8.2/angular.min.js"></script>

</head>

<body ng-controller="CounterController as ctrl">



<h1>Count: {{ ctrl.count }}</h1>

<h2>Double Count: {{ ctrl.doubleCount() }}</h2>

<button ng-click="ctrl.increment()">+1</button>



<script>

  angular.module('myApp', [])

    .controller('CounterController', function() {

      var vm = this;

      vm.count = 0;



      vm.increment = function() {

        vm.count++;

        console.log('Latest count:', vm.count);

      };



      vm.doubleCount = function() {

        return vm.count * 2;

      };

  });

</script>

</body>

</html>

但是这种检查机制存在缺陷，例如，当数据量十分庞大时，就会触发非常多次的脏检查机制。

响应式系统

响应式系统 没有出现之前，脏检查机制 是唯一的选择，但是响应式系统凭借快速轻便的特点，立马在江湖上引起了不小的轰动，Angular也放弃了笨重的脏检查机制采用了响应式系统!

// app.component.ts

import { Component } from '@angular/core';



@Component({

  selector: 'app-root',

  template: `

    <h1>Count: {{ count }}</h1>

    <h2>Double Count: {{ doubleCount() }}</h2>

    <button (click)="increment()">+1</button>

  `,

})

export class AppComponent {

  count: number = 0;



  increment() {

    this.count++;

    console.log('Latest count:', this.count);

  }



  doubleCount() {

    return this.count * 2;

  }

}

和我们熟知的Vue的响应式不同，Angular的响应式采用双向数据流的设计，这也使得它在面对复杂项目时，性能和维护上不如Vue快捷方便。

所以，为了更好的驾驭双向数据流的响应式系统，Angular也是自创了很多绝学，例如：局部变更检测。

该绝学主要招式：组件级变更检测策略、引入zonejs、OnPush 策略等。

1. 组件级变更检测策略

每个组件都有自己的更新策略，只有组件的属性和文本发生变化时，才会触发变更检测！

2. 引入zonejs

引入zonejs拦截http setTimeout 用户交互事件等异步操作

3. OnPush 策略

默认情况下，整个组件树在变更时更新。

但是开发者可以选择 OnPush 策略，使得组件仅在输入属性发生变化、事件触发或手动调用时才进行变更检测。这进一步大大减少了变更检测的频率，适用于数据变化不频繁的场景。

Signals系统

很快啊，当SolidJS凭借优异的信号系统在江湖上闯出了响亮的名声，这时，大家才意识到，原来还有更优秀的开发方式！signal系统的开发方式，也被公认为新一代的武林绝技！

于是，Angular 16它来了，它带着signal、memo、effect三件套走来了！

当使用signal时，更新仅仅发生在当前组件。

// app.component.ts

import { Component, signal, effect, memo } from '@angular/core';



@Component({

  selector: 'app-root',

  template: `

    <h1>Count: {{ count() }}</h1>

    <h2>Double Count: {{ doubleCount() }}</h2>

    <button (click)="increment()">+1</button>

  `,

  styles: []

})

export class AppComponent {

  // 使用 signal 来管理状态

  count = signal(0);



  // 使用 memo 来计算 doubleCount

  doubleCount = memo(() => this.count() * 2);



  constructor() {

    // 使用 effect 来监听 count 的变化

    effect(() => {

      console.log('Latest count:', this.count());

    });

  }



  increment() {

    // 更新 signal 的值

    this.count.set(this.count() + 1);

  }

}

总结

Angular 虽然在国内市场一蹶不振，但是在国际市场一直默默耕耘 10 年。它作为一站式解决方案的框架，虽然牺牲了灵活性，但是也为开发者提供了沉浸式开发的选择！

且它不断创新、积极拥抱新技术的精神令人十分钦佩！

今天的内容就这些了，如果你觉得还不错，可以关注我。

如果文章中存在问题，欢迎指正！

在 JavaScript 中，使用 debugger 关键字可以在代码执行到该位置时触发断点调试。这可以帮助开发人员进行代码调试和排错。然而，有些网站开发者可能会故意使用 debugger 关键字来阻止调试，从而增加代码的安全性。但仍然有一些方法可以绕过这种防护措施，进行调试和排错。

禁用浏览器debugger

因为 debugger 其实就是对应的一个断点，它相当于用代码显示地声明了一个断点，要解除它，我们只需要禁用这个断点就好了。

禁用全局断点

全局禁用开关位于 Sources 面板的右上角，如下图所示：

点击它，该按钮会被激活，变成蓝色。

这个时候我们再重新点击一下 Resume script execution(恢复脚本执行)按钮，跳过当前断点，页面就不会再进入到无限 debugger 的状态了。

请注意，禁用所有断点可能会导致你错过一些潜在的问题或错误，因为代码将会连续执行而不会在可能的问题点停止。因此，在禁用所有断点之前，请确保你已经理解了代码的行为，并且明白在出现问题时该如何调试。

禁用局部断点

尝试使用另一种方法来跳过这个无限 debugger。在 debugger 语句所在的行的行号上单击鼠标右键，此时会出现一个快捷菜单，操作下图所示：

添加条件断点

在JS代码 debugger 行数位置的最左侧点击右键，添加条件断点（满足条件才会进入断点），将条件设置为false，就是条件永远不成立，永远不会断下来。

添加条件断点还可以监视获取一些变量信息，还是挺好用的。

如果是简单的debugger断点，直接用上边的方式就可以，如果是通过定时器触发的debugger断点，就需要进行Hook处理了。

以上的方案执行完毕之后有时候会跳转空页面，这时候只需要在空页面上打开原先地址即可。

先打开控制台

有时候我们一打开网页，就直接进入空页面，控制台上的js和html文件也随之为空，这时候需要在空白页面，或者F12等键无法打开控制台等，这种可以先打开控制台，然后再在空白页面上打开网站即可。

可以在这个网站上试一下。

替换文件

直接使用浏览器开发者工具替换修改js（Sources面板 --> Overrides），或者通过FD工具替换。

这种方式的核心思路，是替换 JS 文件中的 debugger 关键字，并保存为本地文件，在请求返回的时候、通过正则匹配等方式、拦截并替换返回的 JS 代码，以达到绕过 debugger 的目的。也可以直接删掉相关的debugger代码。

具体实现可参考：2024最新版JavaScript逆向爬虫教程-------基础篇之无限debugger的原理与绕过

快捷方案-使用油猴等插件

使用这种方法，就不需要再打 script 断点。直接安装插件即可。

参考文献

2024最新版JavaScript逆向爬虫教程-------基础篇之无限debugger的原理与绕过

解决浏览器调试无限debugger

这里我们不介绍禁止右键菜单, 禁止F12快捷键和代码混淆方案。

无限debugger

• 前端页面防止调试的方法主要是通过不断 debugger 来疯狂输出断点，因为 debugger 在控制台被打开的时候就会执行


• 由于程序被 debugger 阻止，所以无法进行断点调试，所以网页的请求也是看不到的.

基础方案

(() => {

  function ban() {

    setInterval(() => { debugger; }, 50);

  }

  try {

    ban();

  } catch (err) { }

})();

• 将 setInterval 中的代码写在一行，可以禁止用户断点，即使添加 logpoint 为 false 也无用


• 当然即使有些人想到用左下角的格式化代码，将其变成多行也是没用的

浏览器宽高

根据浏览器宽高、与打开F12后的宽高进行比对，有差值，说明打开了调试，则替换html内容；

• 通过检测窗口的外部高度和宽度与内部高度和宽度的差值，如果差值大于 200，就将页面内容设置为 "检测到非法调试"。


• 通过使用间隔为 50 毫秒的定时器，在每次间隔内执行一个函数，该函数通过创建一个包含 debugger 语句的函数，并立即调用该函数的方式来试图阻止调试器的正常使用。

(() => {

  function block() {

    if (window.outerHeight - window.innerHeight > 200 || window.outerWidth - window.innerWidth > 200) {

      document.body.innerHTML = "检测到非法调试";

    }

    setInterval(() => {

      (function () {

        return false;

      }

      ['constructor']('debugger')

      ['call']());

    }, 50);

  }

  try {

    block();

  } catch (err) { }

})();

关闭断点，调整空页面

在不打开发者工具的情况下，debugger是不会执行将页面卡住，而恰恰是利用debugger的这一点，如果你打开开发者工具一定会被debugger卡住，那么上下文时间间隔就会增加，在对时间间隔进行判断，就能巧妙的知道绝对开了开发者工具，随后直接跳转到空白页，一气呵成。(文心一言采用方案)

setInterval(function () {

  var startTime = performance.now();

  // 设置断点

  debugger;

  var endTime = performance.now();

  // 设置一个阈值，例如100毫秒

  if (endTime - startTime > 100) {

    window.location.href = 'about:blank';

  }

}, 100);

第三方插件

disable-devtool

disable-devtool可以禁用所有一切可以进入开发者工具的方法，防止通过开发者工具进行的代码搬运。

该库有以下特性:

🦂使用🦂

<script disable-devtool-auto src='https://cdn.jsdelivr.net/npm/disable-devtool'>script>

更多使用方法参见官网：disable-devtool

disable-devtool

console-ban禁止 F12 / 审查开启控制台，保护站点资源、减少爬虫和攻击的轻量方案，支持重定向、重写、自定义多种策略。

使用

<head>

  

  <script src="https://cdn.jsdelivr.net/npm/console-ban@5.0.0/dist/console-ban.min.js">script>

  <script>

    // default options

    ConsoleBan.init()

    // custom options

    ConsoleBan.init({

      redirect: '/404'

    })

  script>

head>

在项目中使用：

  yarn add console-ban

import { init } from 'console-ban'



init(options)

重定向

ConsoleBan.init({

  // 重定向至 /404 相对地址

  redirect: '/404',

  // 重定向至绝对地址

  redirect: 'http://domain.com/path'

})

使用重定向策略可以将用户指引到友好的相关信息地址（如网站介绍），亦或是纯静态 404 页面，高防的边缘计算或验证码等页面。

注：若重定向后的地址可以通过 SPA 路由切换或 pjax 局部加载技术等进行非真正意义上的页面切换，则切换后的控制台监测将不会再次生效，对于 SPA 你可以在路由卫士处重新注册本实例，其他情况请引导至真正的其他页面。

重写

var div = document.createElement('div')

div.innerHTML = '不要偷看啦~'



ConsoleBan.init({

  // 重写 body 为字符串

  write: '
 不要偷看啦~ 
',

  // 可传入节点对象

  write: div

})

重写策略可以完全阻断对网站内容的审查，但较不友好，不推荐使用。

回调函数

ConsoleBan.init({

  callback: () => {

    // ...

  }

})

回调函数支持自定义打开控制台后的策略。

参数

注：redirect、write、callback 三种策略只能取其一，优先使用回调函数。

参考文章

禁止别人调试自己的前端页面代码

前端防止恶意调试

禁止调试，阻止浏览器F12开发者工具

前端防止调试技术

结语

需要注意的是，这些技术可以增加攻击者分析和调试代码的难度，但无法完全阻止恶意调试。因此，对于一些敏感信息或关键逻辑，最好的方式是在后端进行处理，而不是完全依赖前端来保护。

下篇文章主要介绍如何破解这些禁止调试的方法。

矛与盾：⚔️不让我在控制台上调试，哼，休想🛠️

一. 🎯 变局中抓住核心

这个春节被DeepSeek消息狂轰滥炸，很多做IT朋友已经敏锐的意识到 一场变局已经酝酿，整个IT行业都将迎来洗牌重塑。 中小IT企业、个人创业者、普通人该如何面对这场变局，如何不被市场淘汰，如何抓住机遇？

先说结论

2025年，谁能将

🔥技术热点 转换成 🚀业务引擎

谁就能在这场变局中抢得先机

2025年，选择躺平视而不见，以后的路将越来越窄

二. 🧐 AI巨头垄断，小公司别硬刚

头部AI/大模型厂商 （OpenAI、DeepSeek、字节、阿里、百度…）

通过大模型底座控制生态入口

中小IT公司沦为“AI插件开发者”

⬇️

说直白点就是别学大厂烧钱训练大模型

“不要用你搬砖攒下的血汗钱挑战巨头们躺赚的钱袋子”

合理的生存之计是：

• 直接调用低成本接入大厂的大模型能力


• 通过云服务+开源模型聚焦1-2个细分垂直赛道开发领域专属大模型应用

当然你也可以不信邪

学习DeepSeek不走寻常路

十年量化无人问，一朝DS天下知

闷声鼓捣一个大的

三. 🖊️ 产品思维要转变

对于产品现在客户要的不是功能，是智商

产品的设计思路一定是

从功能导向 ➡️ 智能导向

堆功能堆指标是底限，堆智能才是上限

无论是硬件还是软件公司，殊途同归

卖硬件 ➡️ 卖智能，卖软件 ➡️ 卖智能

四. 🔧 定制化服务市场潜力大

虽然AI巨头都推出了N个

行业标准化AI解决方案

以近乎成本价抢占市场

但是，中国客户还是喜欢”定制化“

有数据统计，60%以上的行业需求无法被标准化方案满足

• 中小IT公司：
  
  
  
  
  • 大厂不愿做，我做 📣
  
  
  • 大厂不屑做，我做 📣
  
  
  • 大厂不会做，我做 📣
  
  
  
  

比如，

现在做企业AI应用开发

需要触碰企业长年积累的数据

客户有很强意识👉🏻这是核心资产

所以开发时，就要求定制化+本地化

• 只有定制化，才能构建数据护城河


• 只有定制化，客户对数据隐私才放心
  ...

也许这不是真理，但却是刚需

总之，客户定制化理由千千万万

这就是IT人的机会

五. 💰 在你懂而别人不懂的领域赚钱

小公司

• 聚焦“AI+垂直场景”做深行业Know-How


• 避免与通用大模型正面竞争

中等公司

• 构建“私有化模型+数据闭环”


• 在特定领域建立技术壁垒

六. 💯 存量市场以稳为主，增量市场探索可能

存量业务

• 用AI改造现有产品和客户场景


• 对于已经稳定的客户和产品应当积极引入 AI 技术进行升级改造

增量市场

• 探索AI原生需求


• 要善于挖掘客户对AI的新需求并及时满足，抢占市场先机

此过程中，有两点需要注意

• 敏捷性 > 规模
  
  
  
  
  • 快速试错、小步快跑的模式比巨额投入更重要
  
  
  
  


• 场景落地 > 技术炫技
  
  
  
  
  • 能解决具体业务痛点的“60分AI方案”比追求“99分技术指标”更易存活
  
  
  
  

七. 💥 纯技术团队将面临淘汰

开发团队

• 必须重构开发流程


• 建立“AI+人工”混合开发模式


• 开发流程需和AI工具链深度集成


• 开发不要过重，采用轻量化技术路线

部署和运维团队

• 同样建立“AI+人工”混合运维模式


• 智能运维手段（故障预测、根因分析）将成标配


• 内部要刻意培养AI-Aware工程师

未来技术人员的筛选条件可能不再是年龄、学历、工作经验而是你有没有 AI Awareness

八. 📝 总结

在这场变局中能活好的普通IT公司，AI创业者

不一定是技术最强的

而是最会借力AI

用行业经验+客户积累+AI工具

做巨头看不上的 “小而美”生意 🤩

表妹问：前端好玩吗？我说好玩，但表妹接下来的回复看哭了我。

是的，回复如下：

这红海血途上，新兵举着 "大前端" 旌旗冲锋，老兵拖着node_modules残躯撤退。资本织机永不停歇，框架版本更迭如暴君换季，留下满地deprecated警告如秋后落叶。

其一、夹缝中的苦力

世人都道前端易，不过调接口、改颜色，仿佛稚童搭积木。却不知那屏幕上寸寸像素之间，皆是血泪。产品拍案，需求朝夕三变，昨日之红蓝按钮，今晨便成黑白圆角。UI稿纸翻飞如雪，设计师手持“用户体验”四字大旗，将五更赶工的代码尽数碾碎。后端端坐高台，接口文档空悬如镜花水月，待到交付时辰，方抛来残缺数据。此时节，前端便成了那补天的女娲，于混沌中捏造虚拟对象，用JSON.parse('{"data": undefined}')这等荒诞戏法，将虚无粉饰成真实。

看这段代码何等悲凉：

// 后端曰：此接口返data字段，必不为空

fetch('api/data').then(res => {

  const { data } = res;

  render(data[0].children[3].value || '默认值'); // 层层掘墓，方见白骨

});

此乃前端日常——在数据废墟里刨食，用||与?.铸成铁锹，掘出三分体面。

其二、技术的枷锁

JavaScript本是脚本小儿，如今却要扛鼎江山。君不见React、Vue、Angular三座大山压顶，每年必有新神像立起。昨日方学得Redux真经，今朝GraphQL又成显学。更有Electron、ReactNative、Flutter诸般法器，教人左手写桌面应用，右手调移动端手势。所谓“大前端”，实乃资本画饼之术，人前跨端写，人后页面仔——既要马儿跑，又言食草易。

且看这跨平台代码何等荒诞：

// 一套代码统治三界（iOS/Android/Web）

<View>

  {Platform.OS === 'web' ? 

    <div onClick={handleWebClick} /> : 

    <TouchableOpacity onPress={handleNativePress} />

  }

</View>

此类缝合怪代码，恰似给长衫打补丁，既失体统，又损性能。待到内存泄漏、渲染卡顿时，众人皆指前端曰："此子学艺不精！"

何人怜悯前端 node18 react19 逐人老，后端写着 java8 看着 java22 笑。

其三、尊严的消亡

领导提拔，必先问尔可懂SpringBoot、MySQL分库分表？纵使前端用WebGL绘出三维宇宙，用WebAssembly重写操作系统，在会议室里仍是“做界面的”。工资单上数字最是直白——同司后端新人起薪一万五，前端老将苦熬三年方摸得此数。更可笑者，产品经理醉酒时吐真言："你们不就是改改CSS么？"

再看这可视化代码何等心酸：

// 用Canvas画十万级数据点

ctx.beginPath();

dataPoints.forEach((point, i) => {

  if (i % 100 === 0) ctx.stroke(); // 分段渲染防卡死

  ctx.lineTo(point.x, point.y);

});

此等精密计算，在他人眼中不过"动画效果"，与美工修图无异。待浏览器崩溃，众人皆曰："定是前端代码劣质！"

技术大会，后端高谈微服务、分布式，高并发，满座掌声如雷，实则系统使用量百十来人也是远矣；前端言及 CSS 栅格、浏览器渲染，众人瞌睡连天。领导抚掌笑曰：“后端者，国之重器；前端者，雕虫小技。” 晋升名单，后端之名列如长蛇，前端者埋没于墙角尘埃。纵使将那界面写出花来，终是 “美工” 二字定终身。

其四、维护者的悲歌

JavaScript本无类型，如野马脱缰。若非经验老道之一，常写出这等代码：

function handleData(data) {

  if (data && typeof data === 'object') { // 万能判断

    return data.map(item => ({

      ...item,

      newProp: item.id * Math.random() // 魔改数据

    }));

  }

  return []; // 默认返回空阵，埋下百处报错

}

此类代码如瘟疫蔓延，领导却言“这些功能实习生也能写！”，却不顾三月后连作者亦不敢相认，只得下任前端难上加难。

而后端有Type大法，编译检查护体，有Swagger契约，有Docker容器，纵使代码如乱麻，只需扩内存、增实例，便可遮掩性能疮疤。

其五、末路者的自白

诸君且看这招聘启事："需精通Vue3+TS+Webpack，熟悉React/Node.js，有Electron/小程序经验，掌握Three.js/WebGL者重点考虑。" 薪资却标着"6-8K"。更有机智者发明"全栈"之名，实欲以一人之躯，承三头六臂之劳。

再看这面试题何等荒谬：

// 手写Promise实现A+规范

class MyPromise {

  // 三千行后，方知自己仍是蝼蚁

}

此等屠龙之术，入职后唯调API用。恰似逼庖丁解牛，却令其日日杀鸡。

或以使用组件库之经验薪资招之，又以写不好组件库之责裁出。

尾声：铁屋中的叩问

前端者，数字化时代的纺织工也。资本织机日夜轰鸣，框架如梭穿行不息。程序员眼底血丝如网。所谓"全栈工程师"，实为包身工雅称；所谓"技术革新"，不过剥削新法。

若仍有少年热血未冷，欲投身此业，且听我一言：君有凌云志，何不学Rust/C++，做那操作系统、数据库等真·屠龙技？莫要困在这CSS牢笼中，为圆角像素折腰，为虚无需求焚膏。前端之路，已是红海血途，望后来者三思，三思！

Spring生态重大升级全景图

一、Spring 6.0核心特性详解

1. Java版本基线升级

• 最低JDK 17：全面拥抱Java模块化特性，优化现代JVM性能


• 虚拟线程（Loom项目）：轻量级线程支持高并发场景（需JDK 19+）

// 示例：虚拟线程使用

Thread.ofVirtual().name("my-virtual-thread").start(() -> {

    // 业务逻辑

});

• 
  
  
  
  1. 虚拟线程（Project Loom）
  
  
  
  


• 应用场景：电商秒杀系统、实时聊天服务等高并发场景

// 传统线程池 vs 虚拟线程

// 旧方案（平台线程）

ExecutorService executor = Executors.newFixedThreadPool(200);

// 新方案（虚拟线程）

ExecutorService virtualExecutor = Executors.newVirtualThreadPerTaskExecutor();

// 处理10000个并发请求

IntStream.range(0, 10000).forEach(i -> 

    virtualExecutor.submit(() -> {

        // 处理订单逻辑

        processOrder(i);

    })

);

2. HTTP接口声明式客户端

• @HttpExchange注解：类似Feign的声明式REST调用

@HttpExchange(url = "/api/users")

public interface UserClient {

    @GetExchange

    List<User> listUsers();

}

应用场景：微服务间API调用

@HttpExchange(url = "/products", accept = "application/json")

public interface ProductServiceClient {

    @GetExchange("/{id}")

    Product getProduct(@PathVariable String id);

    @PostExchange

    Product createProduct(@RequestBody Product product);

}

// 自动注入使用

@Service

public class OrderService {

    @Autowired

    private ProductServiceClient productClient;

    

    public void validateProduct(String productId) {

        Product product = productClient.getProduct(productId);

        // 校验逻辑...

    }

}

3. ProblemDetail异常处理

• RFC 7807标准：标准化错误响应格式

{

  "type": "https://example.com/errors/insufficient-funds",

  "title": "余额不足",

  "status": 400,

  "detail": "当前账户余额为50元，需支付100元"

}

• 应用场景：统一API错误响应格式

@RestControllerAdvice

public class GlobalExceptionHandler {

    @ExceptionHandler(ProductNotFoundException.class)

    public ProblemDetail handleProductNotFound(ProductNotFoundException ex) {

        ProblemDetail problem = ProblemDetail.forStatus(HttpStatus.NOT_FOUND);

        problem.setType(URI.create("/errors/product-not-found"));

        problem.setTitle("商品不存在");

        problem.setDetail("商品ID: " + ex.getProductId());

        return problem;

    }

}

// 触发异常示例

@GetMapping("/products/{id}")

public Product getProduct(@PathVariable String id) {

    return productRepo.findById(id)

           .orElseThrow(() -> new ProductNotFoundException(id));

}

4. GraalVM原生镜像支持

• AOT编译优化：启动时间缩短至毫秒级，内存占用降低50%+


• 编译命令示例：

native-image -jar myapp.jar

二、Spring Boot 3.0突破性改进

1. 基础架构升级

• Jakarta EE 9+：包名javax→jakarta全量替换


• 自动配置优化：更智能的条件装配策略


• 
  
  
  
  1. OAuth2授权服务器
     应用场景：构建企业级认证中心
  
  
  
  

# application.yml配置

spring:

  security:

    oauth2:

      authorization-server:

        issuer-url: https://auth.yourcompany.com

        token:

          access-token-time-to-live: 1h

定义权限端点

@Configuration

@EnableWebSecurity

public class AuthServerConfig {

    @Bean

    public SecurityFilterChain authServerFilterChain(HttpSecurity http) throws Exception {

        http

            .authorizeRequests(authorize -> authorize

                .anyRequest().authenticated()

            )

            .oauth2ResourceServer(OAuth2ResourceServerConfigurer::jwt);

        return http.build();

    }

}

2. GraalVM原生镜像支持

应用场景：云原生Serverless函数

# 打包命令（需安装GraalVM）

mvn clean package -Pnative

# 运行效果对比

传统JAR启动：启动时间2.3s | 内存占用480MB

原生镜像启动：启动时间0.05s | 内存占用85MB

3. 增强监控（Prometheus集成）

• Micrometer 1.10+：支持OpenTelemetry标准


• 全新/actuator/prometheus端点：原生Prometheus格式指标


• 应用场景：微服务健康监测

// 自定义业务指标

@RestController

public class OrderController {

    private final Counter orderCounter = Metrics.counter("orders.total");

    @PostMapping("/orders")

    public Order createOrder() {

        orderCounter.increment();

        // 创建订单逻辑...

    }

}

# Prometheus监控指标示例

orders_total{application="order-service"} 42

http_server_requests_seconds_count{uri="/orders"} 15

三、升级实施路线图

四、新特性组合实战案例

场景：电商平台升级

// 商品查询服务（组合使用新特性）

@RestController

public class ProductController {

    // 声明式调用库存服务

    @Autowired

    private StockServiceClient stockClient;

    // 虚拟线程处理高并发查询

    @GetMapping("/products/{id}")

    public ProductDetail getProduct(@PathVariable String id) {

        return CompletableFuture.supplyAsync(() -> {

            Product product = productRepository.findById(id)

                             .orElseThrow(() -> new ProductNotFoundException(id));

            

            // 并行查询库存

            Integer stock = stockClient.getStock(id);

            return new ProductDetail(product, stock);

        }, Executors.newVirtualThreadPerTaskExecutor()).join();

    }

}

四、升级实践建议

通过以上升级方案：

本次升级标志着Spring生态正式进入云原生时代。重点关注：虚拟线程的资源管理策略、GraalVM的反射配置优化、OAuth2授权服务器的定制扩展等深度实践方向。

面试官问：“你能接受加班吗？”我脑袋嗡的一声，余音绕梁三日不绝于耳。

那一刻，我简直觉得自己像被突然砸中脑袋，脑袋里嗡的一声，余音绕梁三日。作为一个职场小白，这种问题简直颠覆了我对面试的认知。于是，我一时心血来潮，脱口而出一句：“领导抗揍吗？” 结果，大家猜到了，面试是上午结束的，Offer是当天中午凉的。

如何巧妙回答

“我认为加班是工作中不可避免的一部分，尤其是在一些特殊项目或紧急情况下。我非常热爱我的工作，并且对公司的发展充满信心，因此我愿意为了团队的成功付出额外的努力。当然，我也注重工作效率和时间管理，尽量在正常工作时间内完成任务。如果确实需要加班，我也会根据公司合理的安排，积极的响应。”

作为一名资深的面试官，今天面对这个问题，坐下来和大家聊聊应该怎么回答呢？面试官究竟喜欢怎样的回答？让我们深入分析一下。

面试官的心理

在职场中，想要出色地应对面试，需要具备敏锐的观察力和理解力。学会细致入微地观察，善于捕捉每一个细微的线索，这样才能在面试中游刃有余。懂的察言观色，方能尽显英雄本色。

面试官的考量点

• 评估工作稳定性

面试官提出“能否接受加班”的问题，旨在深入了解求职者的职业稳定性和对加班安排的适应性。这一评估有助于预测求职者入职后的表现和长期留任的可能性。工作稳定性是企业考量员工的关键指标之一，通过这一问题，面试官能够洞察求职者的职业发展规划及其对未来工作的期望。

• 筛选合适的候选人

通过询问加班的接受度，面试官筛选出那些愿意为达成工作目标而投入额外时间和精力的候选人。这种筛选方式有助于确保团队的整体运作效率和协作精神。合适的候选人不仅能快速融入团队，还能显著提升工作效率。因此，面试官借此问题寻找最匹配岗位需求的员工。

• 了解求职者的价值观

面试官还利用这个问题来探查求职者的价值观和工作态度，以此判断他们是否与公司的文化和核心价值观相契合。员工的价值观和态度对公司的长远发展起着至关重要的作用。通过这一询问，面试官能够确保求职者的个人目标与公司的发展方向保持一致，从而促进整体的和谐与进步。

考察的问题的意义

要理解问题的本质……为什么面试官会提出这样的问题？难道是因为你的颜值过高，引发了他的嫉妒？

• 工作态度

面试官通过询问加班的接受度，旨在评估求职者是否展现出积极的工作态度和强烈的责任心。在许多行业中，加班已成为常态，面试官借此问题了解求职者是否愿意在工作上投入额外的时间和精力。积极的工作态度和责任心是职场成功的关键因素，通过这一问题，面试官能够初步判断求职者是否适应高强度的工作环境。

• 岗位匹配度

特定岗位因其工作性质可能需要频繁加班。面试官通过提出加班相关的问题，旨在了解求职者是否能适应这类岗位的工作强度。由于不同岗位对工作强度的要求各异，面试官希望通过这一问题确保求职者对即将承担的角色有明确的认识，从而防止入职后出现期望不一致的情况。

• 抗压能力

加班往往伴随压力，面试官通过这一问题考察求职者的抗压能力和情绪管理技巧。抗压能力对于职场成功至关重要，面试官借此了解求职者在高压环境下的表现，以判断其是否符合公司的需求。

• 公司文化

面试官还利用这个问题来评估求职者对公司加班文化的接受程度，以此判断其价值观是否与公司相符。公司文化对员工的工作体验和满意度有着深远的影响，面试官希望通过这一问题确保求职者能够认同并融入公司文化。

回答的艺术

“知己知彼，百战不殆。”在面试中，回答问题的关键在于展现出积极和正向的态度。

• 积极态度

在回答有关加班的问题时，表达你对工作的热爱和对公司的忠诚，强调你愿意为了团队的成功而付出额外的努力。这种积极的态度不仅展示了你的职业素养和对工作的热情，还能显著提升面试官对你的好感。

例如：“我非常热爱我的工作，并且对公司的发展充满信心。我相信为了实现公司的目标和团队的成功，适当的加班是可以接受的。”

• 灵活性和效率

强调你在时间管理和工作效率上的能力，表明你在确保工作质量的同时，会尽可能减少加班的需求。灵活性和效率是职场中极为重要的技能，面试官可以通过这个问题了解你的实际工作表现。

例如：“我在工作中注重效率和时间管理，通常能够在规定的工作时间内完成任务。当然，如果有特殊情况需要加班，我也会全力以赴。”

• 平衡工作与生活

适当地提到你对工作与生活平衡的重视，并希望公司在安排加班时能够充分考虑到员工的个人需求。平衡工作与生活是职场人士普遍关注的问题，面试官通过这个问题可以了解你的个人需求和期望。

例如：“我非常重视工作与生活的平衡，希望在保证工作效率的同时，也能有足够的时间陪伴家人和进行个人活动。如果公司能够合理安排加班时间，我会非常乐意配合。”

• 适度反问

在回答时，可以适当地向面试官询问关于公司加班的具体情况，以便更全面地了解公司的加班文化和预期。这样的反问可以展现你的主动性和对公司的兴趣，有助于获取更多信息，做出更加明智的回答。

例如：“请问公司通常的加班情况是怎样的？是否有相关的加班补偿或调休安排？”

最后

所谓士为知己者死，遇良将则冲锋陷阵，择良人则共谋天下。在职场这场没有硝烟的战争中，我们每个人都是一名战士，寻找着属于自己的知己和良将。当面试官提出挑战性问题时，我们不仅要展示自己的能力和才华，更要表现出对工作的热爱和对公司的忠诚。

面对“你能接受加班吗？”这样的问题，我们应以积极的态度、灵活的思维和对工作与生活平衡的重视来回应。这样的回答不仅能展示我们的职业素养，还能让我们在众多求职者中脱颖而出，赢得面试官的青睐。

正如士为知己者死，我们在职场中也要找到那个能理解我们、支持我们的知己；遇良将则冲锋陷阵，我们要在优秀的领导下发挥自己的潜能，为公司的发展贡献力量；择良人则共谋天下，我们要与志同道合的同事共同努力，实现职业生涯的辉煌。

总之一句话，在面试中展现出积极向上的形象，不仅能为我们的职业生涯加分，更能让我们在职场上找到属于自己的价值和归属感。让我们以这句话为指引，勇敢地迎接职场的挑战，书写属于自己的辉煌篇章。

欢迎关注我的训练营：云原生AI实战营，一个助力 Go 开发者在 AI 时代建立技术竞争力的实战营。

今天分享下 DeepSeek 对于编程语言未来的预测，这个应该也是很多开发者关注的，因为它可能会影响未来的职业选择。

因我自己最近也在关注这方面，所以今天就问了 DeepSeek。DeepSeek 给出的回答跟我的想法很一致，所以今天把 DeepSeek 的回答分享出来。

问题：Go、Java、Rust、Python 语言未来前景如何

我的问题是Go、Java、Rust、Python 语言未来前景如何。之所以问这 4 门语言，是因为这四门语言在后端开发中最受欢迎，各自在其擅长的领域中发光发热。

目前，我觉得 Go 和 Java 在领域上有一定程度或者很大程度的重合。Rust、Python、（Go、Java）有其擅长的领域，交叉点不多。

我想弄明白的是，每门语言是否会在其领域继续发展状态，或者会有蚕食其他领域的现象。通过这些，也想知道未来编程语言的选型为何。

DeepSeek 思考过程

提示：以下是 DeepSeek 的思考过程

好的，用户问的是Go、Java、Rust、Python这四种语言的未来前景如何。我需要逐一分析每种语言的特点、现状以及发展趋势，同时比较它们的优缺点和应用场景。首先，我应该回忆每种语言的主要用途和社区活跃度，然后看看市场需求和技术趋势。

对于 Go 语言，它由Google开发，以高并发和高效编译著称，适合云原生和微服务。近年来Docker、Kubernetes的流行推动了Go的应用，尤其是在后端和DevOps领域。但Go在泛型和生态系统方面可能不如其他语言，所以需要评估这些因素是否会影响其未来。

Java作为老牌企业级语言，稳定性强，广泛应用于大型系统、Android开发和大数据。虽然有人认为Java在下降，但它的庞大现有代码库和企业依赖意味着它仍会长期存在。不过，Java需要面对Kotlin等语言的竞争，尤其是在Android开发方面，还有云原生趋势下轻量级语言的挑战。

Rust以内存安全和性能为卖点，逐渐在系统编程、嵌入式和高性能计算领域崭露头角。被Linux内核和Windows驱动采用，说明其潜力。但Rust的学习曲线陡峭，可能在普及上需要时间，但在对安全性要求高的领域会持续增长。

Python作为脚本语言之王，在数据科学、AI、Web开发等领域占据主导。随着AI的爆发，Python的需求持续增长，但性能问题可能在需要高性能的场景中成为瓶颈。不过，Python的易用性和丰富的库支持使其在教育和小型项目中保持优势。

接下来要考虑的是行业趋势，比如云计算的持续增长对Go有利，AI发展促进Python，系统级需求推动Rust，而企业维护则维持Java。同时，新语言的出现是否会影响这些老牌语言，例如Rust可能替代部分C/C++的领域，而Go可能继续在云原生领域扩展。

用户可能的深层需求是选择学习方向或技术选型，需要明确各语言的优劣势和适用场景，帮助他们做出决策。因此，回答时要突出各语言的优势领域和未来可能的发展方向，以及潜在的风险点，比如Java可能面临市场份额被蚕食，但不会很快消失。

总结部分需要对比各语言，指出它们在不同领域的地位，并给出建议，比如根据项目需求选择合适语言，而不是盲目跟风。同时，强调多语言掌握的重要性，因为现代开发往往需要多种技术结合。

DeepSeek R1 四种语言前景分析

以下是 DeepSeek R1 关于 Go、Java、Rust、Python 四种语言的前景分析，结合技术趋势、市场需求和生态系统发展分析如下：

1. Go (Golang)

优势领域：

• 云原生与微服务：Go 的并发模型（goroutine）和高效编译特性使其成为 Kubernetes、Docker、Istio 等云原生工具的首选语言。


• 高性能后端：适合 API 网关、分布式系统、实时通信等高并发场景（如 Twitch、Uber 的后端）。


• 开发效率：语法简洁，编译速度快，适合快速迭代的工程团队。

未来前景：

• 持续增长：随着云计算的普及，Go 在云原生领域的地位将进一步巩固。


• 企业采用：越来越多公司（如字节跳动、腾讯）将 Go 作为核心后端语言。


• 挑战：泛型支持的完善程度、生态多样性仍需提升。

推荐方向：云原生开发、基础设施工具链、高性能服务端。

2. Java

优势领域：

• 企业级应用：银行、电信、政府等传统行业的核心系统（如 IBM、Oracle 的解决方案）。


• Android 开发：仍占据主导地位（尽管 Kotlin 在 Android 中逐渐取代）。


• 大数据生态：Hadoop、Spark、Flink 等框架依赖 Java 生态。

未来前景：

• 稳定但缓慢衰退：Java 的存量市场庞大，但新项目可能更倾向于现代语言（如 Kotlin、Go）。


• 云原生转型：Quarkus、Spring Native 等框架帮助 Java 适应云原生环境。


• 挑战：冗长的语法、内存消耗较高，对轻量级场景竞争力不足。

推荐方向：传统企业系统维护、Android 底层开发、大数据工程。

3. Rust

优势领域：

• 系统编程：取代 C/C++ 的潜力（如操作系统、嵌入式、浏览器引擎）。


• 内存安全：所有权模型彻底解决内存泄漏和数据竞争问题，适合对安全性要求极高的场景（如区块链、金融系统）。


• 高性能计算：在游戏引擎、实时渲染等领域逐渐应用（如 Discord 的音频服务）。

未来前景：

• 高速增长：被 Linux 内核、Windows 驱动开发等官方支持，逐步进入主流。


• 生态扩展：WebAssembly、区块链（如 Solana）等领域对 Rust 需求激增。


• 挑战：学习曲线陡峭，中小型项目采用成本较高。

推荐方向：系统级开发、安全敏感型应用、区块链底层。

4. Python

优势领域：

• 数据科学与 AI：TensorFlow、PyTorch、NumPy 等库的绝对统治地位。


• 脚本与自动化：运维、测试、爬虫等场景的首选语言。


• 教育与科研：语法简单，适合快速验证算法和原型开发。

未来前景：

• AI 驱动的霸主：随着生成式 AI（如 ChatGPT）的爆发，Python 需求将持续增长。


• 性能瓶颈：在需要高性能的场景（如高频交易）可能被 Rust/Go 取代。


• 生态护城河：庞大的库和社区资源确保其长期不可替代性。

推荐方向：机器学习工程、数据分析、快速原型开发。

综合对比与趋势总结

未来 5 年预测：

建议：

• 根据职业目标选择：
  
  
  
  • 追求高薪和前沿技术：优先 Rust 或 Go。
  
  
  • 稳重型职业发展：Java 或 Python。
  
  
  
  


• 多语言组合：例如 Python（AI） + Go（后端） 或 Rust（底层） + Python（脚本）。

个人观点

提示：以下是我个人总结，非 DeepSeek 的输出。

DeepSeek R1 对于四种语言的前景分析、未来 5 年预测及给出的建议，其实跟我的想法是完全一致的。

根据 JetBrains2024 的市场调研，Go 在四种语言中的工资是最高的，背后的原因可能是因为云原生的技术门槛。Go 在云原生领域占据霸主地位，而云原生本身技术门槛要比业务 CURD 高很多，所以薪资自然要比其他语言高。其实，这也说明了，越是门槛高、技术含量高的岗位薪资越有竞争力（这是一句废话）。

Python 依托于其强大的生态及数据处理能力，在 AI 领域成为霸主语言。在 AI 时代，程序员不可避免的要去学习、掌握 Python。

Rust 优点是高性能、高安全，但缺点是学习门槛高、开发效率相较于 Go 低。所以 Rust 很适合系统层软件的开发，反倒不适合应用层软件的开发。在一个业务向的企业中，一般系统层会使用云基础设施，非核心的系统层，也可以用 Go 语言开发。当前很多优秀的系统层软件都是基于 Go 语言开发的。

所以，在一个企业中，系统层软件和应用层软件，往往是二选一的关系，也意味着，在编程语言上，也有了明确的选择：应用型企业选择 Go。如果企业核心产品是系统层软件，那么可以选择 Rust。

所以最终的编程语言选择一般是：Python（AI） + Go（后端） 或 Rust（底层） + Python（AI）。

当然，企业完全可以根据需要选择更多的编程技术栈组合。上述只是介绍一种通用情况下的选择建议。

另外，在编程语言选择时，建议主攻一门核心语言，同时根据职业目标补充其他相关语言，或者在不同阶段调整策略。这样既避免单一风险，又保持专业性。

浣熊say官方网站：hxsay.com/

浣熊say官方星球：​hxsay.com/about/我的星球/…

正文

不知道最近大家有没有发现，越来越多的人在职业选择上都偏向与央国企、体制内等稳定性较高的岗位，而放弃了去私企、互联网等工资高但是强度大的工作。

从我身边的人了解到这一趋势不仅仅存在于工作了多年的职场老油条，希望找个地方躺平，在应届毕业生的群体里面也越来越明显。然而放在10年前，也就是2014年的时候谁毕业要是去国企、体制内可能会被笑话没有理想、躺平。

但是这两年风向仿佛突然变化了，公务员、央国企突然之间变得香了起来，似乎打工人也随着年龄的增长突然明白了一个道理，比起靠着燃烧生命加班挣来的卖命钱以及生活在不知道什么时候就会被干掉的压力之下，不如稳定的央国企来得实在。

35岁被毕业和干到退休的收入差距有多大？

首先叠甲，我这里说的国企是垄断央企的二级以上的公司或者省属国企总部，这些国企一般掌握着国家、省级的核心资源，不违法犯罪的情况下大概率是能干到退休的。当然，如果有人跟我杠说什么某某银行科技子公司，某某央企的孙子公司一样末尾淘汰，一样裁员不稳定，那么我只能说你说得都对！

假设我硕士毕业就去国企，然后月薪8k，2个月年终（央企二级公司，省属国企很容易达到），那么一年的收入是14*0.8 = 11.2w，然后男性目前的法定退休年龄是65岁，从25岁～65岁工作40年，总收入为 448w。

假设你硕士毕业就去互联网大厂，然后月薪3w，4个月年终（这里也是取得平均值来估计的），那么一年的收入为48w，然后35岁一般确实是互联网的大限，25～35岁工作10年，总收入为：480w。

其实，大多数情况下互联网大厂拿到3w的也是凤毛麟角，国企8k一个月的其实还是遍地都是，甚至一些省会的公务员都能达到8k/月甚至更多，两者职业生涯的总收入其实是差不多的。而且这里为了公平都没有考虑随着工龄增长工资的增长情况，其实在互联网大厂拿到100w年薪的难度远远大于你在国企熬年限，涨到1.5w。

所以，其实无论是选择私企打工挣钱，还是垄断国企躺平，你整个职业生涯获得的工资性收入都是差不多的，以2024年的世界观来看，很多私企甚至很难稳定拿到3w/月的工资到35岁。

有时候一个裁员毕业潮下来，你就不得不面临重新找工作的窘境，以前经济好的时候且没有AI时候，从事技术研发的人还可以自信的说我有技术走到哪里都不怕 。 如今，AI取代大多数工作岗位已经是明牌的事情了，那些掌握技术的人可能也不得不担忧自己能否快速找到合适自己的工作。

虽然，最近两会有委员提出取消35岁的年龄限制，我其实个人并不看好这个提案，因为本质说社会上的私企卡35岁主要是因为廉价、能加班的年轻人太多了，企业处于成本考虑肯定愿意招聘这些年轻人，那么上了年龄的中年人不能加班就可以滚蛋了。 这个事情不是一个提案就能解决的，除非整个职场氛围得到了改变，所有公司都将老员工视作一种公司财富而不是消耗品的时候，才是35岁年龄其实真的消失的时候。

普通打工人还真的需要考虑当你年龄上来之后，失去手头这份工作之后怎么办，你辛辛苦苦寒窗苦读这么多年，出入的高级写字楼，做的都是产值上千万的项目。突然让你失业在家，跑滴滴，送外卖这个心里落差你能接受吗？

当35岁你在街头送着外卖，跑着滴滴，你在央国企的同学或许已经是一个小领导，你去当公务员的同学现在是一个科长，他们再不济也是个小职工有着稳定的收入，不太为生计发愁，不知道那个时候的同学聚会你还有心情去参加不？

对于打工人来说稳定到底意味着什么？

20多岁的年轻人总觉得世界是自己的，脑子里面全部是幻想，总觉得爽文小说当中的主角是自己，不说大富大贵至少能够在企业混的风生水起，升职加薪，当上领导。

这些愣头青的想法我也有过，但是对大多数没有抱上大腿的人来说，工作2～3年之后就会让你明白这个世界的真实运转规则，很多事情不是下位者能够决定的，无论是在国企还是私企，本质上事情还是上位者说了算。

简单来说就是，领导说你行你就是行，领导说你不行那么就赶紧想办法跑路吧。

这种情况在私企、国企其实都会遇到，大家刻板印象中老是说国企的官僚主义严重，但是其实私企才是官僚主义更加严重的地方，而且比起来国企就是小打小闹。

本质上来说在真的央国企你的领导实际上是没有人事权的，他就算再讨厌你也只能通过调岗、扣绩效等方式来恶心你，但是真的没办法裁掉你。

但是在私企领导其实就是你们这个地方的土皇帝，你让领导不开心或者领导不喜欢你，那么是真的可以裁掉你，可能就是一句话的事你下午就不用来上班了都是有可能的事情。在这种地方，你除了舔领导，拼命加班，拼命卷之外没有任何办法，因为上位者掌握着你的生死存亡。

在这种极度竞争和内卷的环境下，你的全部精力都会投入到工作当中，但是其实你并不参与蛋糕的分配，也就是你卷出来的成果、剩余价值大部份被老板拿走了。同时，高强度的工作还会剥夺你其它的可能，让你没时间陪家人，没时间发展自己的事业，当你不得不开始发展自己的事业的时候，就是你已经失业的时候。

而在央国企的工作情况就会好很多，首先大多数岗位是比较稳定的，你不用过于担心失业裁员的情况发生。其次，至少在项目不忙的时候，你的休息时间是可以保障的，利用这些时间你其实可以选择发展自己的事业，就像刘慈心一样写科幻小说未来说不定能从副业上面赚到你一辈子赚不到的钱。

所以，比起那些完全占用你时间和心智的工作，我其实觉得轻松但是钱不那么多的工作更加适合一个人的长期发展，从一生的尺度上看财富积累未必会比短短的靠25～35这10年间挣到的钱少。

为什么这几年央国企火了？

其实很多在校的学弟、学妹们沟通，我发现现在的孩子比我们当年看得明白很多，也可能是不同的时代背景造就了不同的人的观点。

我们还是学生的时候听到的故事还都是什么王者荣耀100个月年终，互联网财富自由之类的神话，但是疫情的3年互联网和诸多的财富神话跌落神坛，大多数普通人能够保住手头的这份工作就是件值得庆幸的事情了。 即使是去华为、阿里、腾讯这样的大厂也很难有机会再实现当年的财富神话，技术改变世界的思潮也正在慢慢退潮，现在这些大厂也很难让你挣到财富自由的钱，逐渐变成了一份普通工作而已。

当你在校园中搏杀了20几年好不容易拿到了学士、硕士、博士文凭，这些私企会告诉你现实的残酷，你手中的文凭只能帮你到入职的3个月，之后就各凭本事了。 资本是逐利的，中国的企业更加喜欢揠苗助长，没有任何培养一个员工的文化在里面。所谓的培养更多的是PUA，告诉你这儿也不行，哪儿也不行，然后在绩效考核的时候顺利成章的把锅甩给你，来满足组长必须找一个倒霉蛋背绩效的制度要求。 我不否认能力极强者、能卷的人在这种环境中能够获得快速的升职加薪和财富，但并不是每个人都是大神，也不是每个人在做好本职工作之外还有心情去舔领导。

入职央国企能够在很大成都上帮你避免上述的问题，大型的央国企平台很大有足够的时间和资源来让员工成长，对于刚入职的新员工可能前面半年都不会给你安排真正意义上的工作，多数是各种培训，各种学习。 我以前经常听到在国企的同学抱怨又是什么培训、什么学习、什么党会，让人觉得很烦没有意义，但是在我看来每个人都应该感恩这些公司花着钱让你不干活儿的活动，真的不是所有的公司都这么有耐心。 除此之外，很少有央国企会期待从你身上压榨什么，因为大多数央国企从事的都是垄断行业，拥有足够的利润，并且这些利润也并非属于领导或者某个人的，而是属于整个集团，国家。你和领导本质上都一样，只是这个国企的打工人，没必要压榨你太过分，毕竟赚的钱也一分不会到领导自己包里，对你个人的包容性也会更强一些。

所以当经济增长变缓，私企难以让人挣到足以财富自由的钱，大家就会发现其实没有必要去承担那么大的压力只是比稳定的工作多一点儿钱。这个时候一份稳定、有自己业余时间的央国企工作性价比就变得更高了起来。一边可以用工资保障自己的生活，一边开拓自己的事业在副业这个第二战场挣到更多的钱，确实会比在私企打工35被裁要体面得多。

The End

其实对于职业的选择，有一个核心逻辑就是去门槛更高的地方。

有的人说，大厂门槛很高啊，问那么多技术，刷那么多题，也是万里挑一才能进去一个人。

但是，实际上这些东西不算门槛，真正的门槛是把人堵在外面的不可逾越的鸿沟，比如说：如果你本科不是学的临床专业，那么你一辈子都没办法当上医生，除非重新高考！这才是真正意义上的门槛，而无论是多么高深的技术，只要肯学都能够学会的。

所以，大型垄断央国企其实是个门槛更高的地方，好的岗位除了应届生就没有就会进去，同时一旦进去占住坑了也很难被裁掉，除非你自己离职。大家可能经常会听说哪个国企的用自己的业余时间努力学习然后去了互联网大厂的。但是你可能完全没有听过那个私企的毕业没去 "中国烟草" 靠着自己的不懈努力，社招进入了中国烟草。

如果是应届生，尽量去门槛高、稳定的地方，考虑长期发展而不是贪图短时间的利益，这样一来即使你的能力没有那么强，也可以用马拉松的方式跑到最后。

人生是一段长跑，不到最后一刻不知道谁输谁赢，就算是活得比别人长，那么其实你最后也胜利了。

大家好，我是二哥呀。

今天我们来聊聊小红书的创始人瞿芳，1985 年出生于湖北武汉，毕业于武汉外国语学校，硕士就读于北京外国语学校。

毕业后进入贝塔斯曼工作，这是一家老牌外企，1835 年就有了，真的非常老，瞿芳在这里工作了 5 年。

瞿芳的执行力也是拉满，2013 年 5 月底离职，6 月赴美寻找风投，7 月初就和老乡毛文超在上海创立了小红书的母公司行吟信息科技有限公司。

长相上我觉得有一点邓丽君的感觉，大家觉得呢？

• 2015-2016 年，瞿芳连续两年被《创业邦》评为“值得关注的女性创业者”；这些年小红书的成长，瞿芳确实功不可没，值得关注。


• 2017 年，瞿芳荣登腾讯“我是创始人”荣耀榜单；小红书背后有阿里和腾讯两家大佬的投资，原来两家是从来不投一家公司的，瞿芳背后的斡旋算是让两家暂时握了手。


• 2020 年，瞿芳入选“中国最具影响力的 30 位商界女性”榜单；目前来看，小红书还处在上升势头，并且流量拉满，瞿芳的身价肯定也会水涨船高。


• 2024 年，瞿芳以 120 亿元的人民币财富位列《2024-胡润榜》的第 433 位；这还是在小红书没有上市的情况下。

瞿芳曾在采访中强调，用户体验和社区氛围是小红书最看重的。

这也是小红书这个平台和微博、抖音最大的区别，你可能在小红书上百粉不到，但发布的内容却会被推荐到平台首页，成为爆款。

微的推荐机制现在也有这种趋势，就是粉丝数越少，反而被推荐的机会越多。

瞿芳认为，品牌与用户的沟通应该从“教学模式”转向“恋爱模式”。

也就是说，我们创作者不能再以老师的角度切入，把读者作为学生来传达信息，而是奔着双方恋爱的方式切入。

更加的纯粹，双方的地位更加的对等。

宝子们，都看到了吧，我爱你们，😄

2013 年的时候，跨境旅游开始兴起，于是，瞿芳就和毛文超一起去找当地的购物达人，把他们的经验编成了一本厚厚的 PDF，书名就叫“小红书”。

这本 PDF 放到网上以后，引起了巨大的反响，一个月的下载量就突破了 50 万次。

尝到了甜头后，瞿芳和毛文超再接再厉，于 2013 年 12 月上线了小红书 App，相当于提供了一个购物的分享平台，注意不是电商平台，而是社区分享平台，让用户来分享自己的购物心得。

这个定位就非常的巧妙。

如果单纯地做电商平台，那么竞争对手多了去，比如说淘宝、天猫、京东，以及拼多多。

但做社区平台的话，当时还没有什么竞争对手，虽然点评和美图秀秀都曾在自己的业务中加入大量的社区内容，并放出豪言，但最终都没有竞争过小红书。

2014 年，小红书就聚集了几百万用户了，于是瞿芳就上线了一款希腊产的清洗液，结果直接被秒光了。

到 2017 年，小红书的营收就突破了 100 亿。

截止到目前，小红书已经发展成为了一个生活社区，基本上你想要的东西，你想找的地方，你想看的美女，小红书上都有。据说，月活用户已经达到了 3 亿。

其中女性用户占比 70%，日均用户搜索渗透率达到 60%，用户生成内容（UGC）占比高达 90%。

根本不需要 KOL。

2025 年 1 月，由于 TikTok 可能会被美国封禁，所以大量的海外用户开始涌入小红书。

中西文化的融合，在此刻显然格外的自然和松弛。

我现在打开小红书，已经很少看到原住民发的东西了，这波算法也被太平洋彼岸的热情感染了。

瞿芳在一次采访中的一段话我觉得很值得分享给大家，我套用一下：

“就像今天手机屏幕前的你们，可能大学生可能是工作党，但不管大家是怎样的身份，回到家里，可能还是会跟家人吃一顿最简单的饭，跟最爱的人一起去做一些有创造性的事情。”

我们要回到生活中去，而不只是活在虚拟世界里。

三分恶面渣逆袭

我这人一向说到做到，每天给大家汇报一下面渣逆袭的进度，这就来。今天修改到第 36 题。

35.你们线上用的什么垃圾收集器？

我们生产环境中采用了设计比较优秀的 G1 垃圾收集器，因为它不仅能满足低停顿的要求，而且解决了 CMS 的浮动垃圾问题、内存碎片问题。

G1 非常适合大内存、多核处理器的环境。

以上是比较符合面试官预期的回答，但实际上，大多数情况下我们可能还是使用的 JDK 8 默认垃圾收集器。

可以通过以下命令查看当前 JVM 的垃圾收集器：

java -XX:+PrintCommandLineFlags -version

UseParallelGC = Parallel Scavenge + Parallel Old，表示新生代用Parallel Scavenge收集器，老年代使用Parallel Old 收集器。

因此你也可以这样回答：

我们系统的业务相对复杂，但并发量并不是特别高，所以我们选择了适用于多核处理器、能够并行处理垃圾回收任务，且能提供高吞吐量的Parallel GC。

但这个说法不讨喜，你也可以回答：

我们系统采用的是 CMS 收集器，能够最大限度减少应用暂停时间。

内容来源

三分恶的面渣逆袭：javabetter.cn/sidebar/san…
二哥的 Java 进阶之路（GitHub 已有 13000+star）：github.com/itwanger/to…

最后，把二哥的座右铭送给大家：没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟。共勉 💪。

哈喽，大家好！我是Web大鹅只会叫！下去沉淀了那么久，终于有时间回来给大家写点什么了！

你问我人为什么活着？我哪知道啊？我又不是上帝！释迦牟尼为了解这个问题还跑去出家，结果发现人活着就是为了涅槃——也就是死。所以别问我人生的意义，我也没搞明白！不过我能告诉你一个答案，那就是裸辞后，我终于知道了为什么要活着——那就是为了“活得自由”！

裸辞后，那些走过的路，和你说的“脏话”

2024年8月，我做了一个震惊所有人的决定——裸辞！是的，没错，我就是那种毫不犹豫地辞了职、丢下稳定收入和安稳生活，拿着背包去走四方的“疯子”。放下了每天早起20公里开车上班的压力，放下了无聊的加班、枯燥的开会，放下了所谓的“你要努力争取美好生活”的叮嘱。一切都在“离开”这一刻轻轻拂去，带着一种挥之不去的自由感。

带着亲人的责怪、朋友的疑问、同事的眼神、以及自己满满的疑惑，我开始了这段没有目的的旅行。我不知道我想找什么，但我知道，我不想再活得像以前那样。

我走过了无数地方，南京、湖州、宁波、杭州、义乌、金华、嘉兴、镇江、扬州、苏州、无锡、上海……一路走来，路过了每个风景，每个城市，每个人生。我甚至去了中国最北的漠河，站在寒风凛冽的雪地里，终于明白了一个道理：“你活着，才是最值得庆祝的事。

你知道吗，最让人清醒的，不是远方的景色，而是走出去之后，终于能脱离了那一套“你该做什么”的公式。每天不用设闹钟，不用准时吃饭，不用打卡上班，不用开会骂娘，再也不被地铁里的拥挤挤得喘不过气。生活突然变得宽松，我竟然开始意识到：我一直追求的美好生活，原来只是在为别人拼命。

走出内卷圈子的那一刻，我认为我是世界上最快乐的小孩了，我们渴望着幸福却糟践着现在，你所期望的美好未来却始终都是下一个阶段！你认为你是一个努力拼搏美好未来的人。可是现实比理想残酷的多！你没日没夜的拼搏，却让别人没日没夜的享受！你用尽自己半条命，换来的是下半辈子的病！我在裸辞后就告诉我自己：从今以后你想干什么、就干什么！你就是世界的主人！ 嗯～ 爽多了！

走过的路，都在暗示我

我在大兴安岭漠河市的市里住了5天，住在一个一天40元的宾馆、干净、暖和！老板是一个退休的铁道工人。脸和双手都布满了冻伤，他的妻子（大姨）很面善。每天都会在我回来的时候和我聊上几句从前，安排一些极寒天气的注意事项。

有一天我去北极村回来，大姨和我聊了一会。大姨对我讲：“趁年轻、别把自己困起来，出去走走。不像我们，60年没出过这片土地，到头还要葬在这片土地上！”。她说这句话的时候没有忧虑、没有悲伤，却是一种满足感。是啊！60多了，还能追求什么？忙了大半辈子，把孩子都送出了这片土地，自己也没有激情出去走走了，很害怕自己的以后也是这样。

我20多岁的年纪，想的不是努力拼搏挣钱、不是搞事业。却总想着无所事事。我觉得自己像一个没有完全“被时间遗弃”的人，我甚至觉得自己不属于这个时代，这个不知道为了什么而拼命的时代。每走一步都好像在掏空自己积压已久的情绪：压力、焦虑、焦灼，让我很享受这种感觉。然后我想起来一本书里的话：“你活着，不是为了活给别人看。“ 是啊，我们都明白这个大道理，可自己从来没打算让自己脱离这个主线。我开始明白，我这次的旅行不是去寻找什么，而是放下什么！

从别人嘴里听到的“脏话”，其实是自己内心的尖刺

这段时间里，我经常回想起来那些让我神经紧绷的日子。尤其是我对“人” 这个物种越来越敏感的那个时期————‘恶毒、自私、无理、肮脏’。朋友的欺骗、同事的推锅、亲人的折磨都是罪恶的！可是到头来，事情还是发生了。地球还是在自转，太阳一样正常升起落下。这些都没有在你认为的这些琐事中消失。我不明白我还在纠结什么？

事实上，这些乱七八糟的事情并不是指向我个人的，它只是我内心脆弱的反射。是的，我一直在内耗自己罢了，把自己放在了一个焦虑的漩涡里。假装没事、假装坚强，结果别人一句话就能作为击垮我的最后一击。直到有一天，我发现我讨厌的只是我自己。所以我决定我不要去在意别人说什么、做什么，我不要逃避问题，我想听听我内心的想法，我不想让自己认为别人在定义我。

过程的意义：也许就是为了“停一停”

好了，我知道我的文采不好，但是也应该有个结尾。

在这一路上，我认识了很多有趣的人，他们不同风格的服装、不同口音，各式各样的生活方式。也有着各式各样的理想和困惑。有的喜欢在山顶等着日出的奇迹，有的则是想在湖边静静地坐着。而我，就是个迷途的羔羊，没有群体头羊的带领，我穿行在这些不同的路途中，慢慢摸索着向所有方向前进着。

偶尔我也会停下来，坐在湖边吹着风、闭上眼睛，听风，感受这一刻的宁静。然后我会微笑，我认为这个时候的我有了轻松的感觉。生活的答案我在这个时候找到了。

我意识到，未来不是重要的，现在才是应该享受的。我不知道我下一步要去哪里，但是我想先停下来看一看，呼吸一下。停下来不是因为我没有了目的，而是我知道，目的地并不重要，重要的是，我和自己在一起，心里不再有那么多焦虑，不再被过去的焦虑所束缚。

所以，我选择了离开，离开这一切，放下所有的焦虑和期待，享受我自己想要的生活。也许，活着的意义不在于追寻一个遥远的目标，而是过好每一个‘现在’。

好人难当，以后要多注意了，涨点记性。记录三件事情证明下：

1. 免费劳动

之前和一个同学一起做一个项目，说是创业，不过项目做好了，倒是他家店铺自己用起来了，后来一直让我根据他家的需求进行修改，我也一一的改了，他倒是挺感谢我的，说是请吃饭。不过也一直没请，后面都一年多过去了，还让我免费帮他改需求，我就说没时间，他说没时间的话可以把源码给他，他自己学着修改，我就直接把源码给他了，这个项目辛苦了一个多月，钱一毛也没赚到，我倒是搭进去一台服务器，一年花了三百多吧。现在源码给他就给他了吧，毕竟同学一场。没想到又过了半年，前段时间又找我来改需求了。这个项目他们家自己拿着赚钱，又不给我一毛钱，我相当于免费给他家做了个软件，还要出服务器钱，还要免费进行维护。我的时间是真不值钱啊，真成义务劳动了。我拒绝了，理由是忙，没时间。

总结一下，这些人总会觉得别人帮自己是理所当然的，各种得寸进尺。

2. 帮到底吧

因为我进行了仲裁，有了经验，然后被一个人加了好友，是一个前同事（就是我仲裁的那家公司），然后这哥们各种问题我都尽心回答，本着能帮别人一点就帮别人一点的想法，但是我免费帮他，他仲裁到手多少钱，又不会给我一毛钱。这哥们一个问题接一个，我都做了回答，后来直接要求用我当做和公司谈判的筹码，我严词拒绝了，真不知道这人咋想的，我帮你并没有获得任何好处，你这个要求有点过分了，很简单，他直接把我搬出来和公司谈判，公司肯定会找我，会给我带来麻烦，这人一点也没想这些事。所以之后他再询问有关任何我的经验，我已经不愿意帮他了。

总结一下，这些人更进一步，甚至想利用下帮自己的人，不考虑会给别人带来哪些困扰。

3. 拿你顶缸

最近做了通过一个亲戚接了一个项目，而这个亲戚的表姐是该项目公司的领导，本来觉得都是有亲戚关系的，项目价格之类开始问了，他们没说，只是说根据每个人的工时进行估价，后面我们每个人提交了个人报价，然后还是一直没给明确答复，本着是亲戚的关系，觉得肯定不会坑我。就一直做下去了，直到快做完了，价格还是没有出来，我就直接问了这个价格的事情，第二天，价格出来了，在我报价基础上直接砍半。我当然不愿意了，后来经过各种谈判，我终于要到了一个勉强可以的价格，期间群里谈判也是我一个人在说话，团队的其他人都不说话。后来前端的那人问我价格，我也把过程都实话说了，这哥们也要加价，然后就各种问我，我也啥都告他了。后来这个前端在那个公司领导（亲戚表姐）主动亮明身份，她知道这个前端和那个亲戚关系好，然后这个前端立马不好意思加价了，并且还把锅甩我头上，说是我没有告诉他她是他姐。还说我不地道，我靠，你自己要加价，关我啥事，你加钱也没说要分我啊，另外我给自己加价的时候你也没帮忙说话啊，我告诉你我加价成功了是我好心，也是想着你能加点就加点吧，这时候你为了面子不加了，然后说成要加价的理由是因为我，真是没良心啊。后面还问我关于合同的事情，我已经不愿意回答他了，让他自己找对面公司问去。

总结一下，这些人你帮他了他当时倒是很感谢你，但是一旦结果有变，会直接怪罪到你头上。

4. 附录文章

这个文章说得挺好的《你的善良，要有锋芒》：

你有没有发现，善良的人，心都很软，他们不好意思拒绝别人，哪怕为难了自己，也要想办法帮助身边的人。善良的人，心都很细，他们总是照顾着别人的情绪，明明受委屈的是自己，却第一时间想着别人会不会难过。

也许是习惯了对别人好，你常常会忽略自己的感受。有时候你知道别人是想占你便宜，你也知道别人不是真心把你当朋友，他们只是觉得你好说话，只是看中了你的善良，但是你没有戳穿，你还是能帮就帮，没有太多怨言。

你说你不想得罪人，你说你害怕被孤立，可是有人在乎过你吗？

这个世界上形形色色的人很多，有人喜欢你，有人讨厌你，你没有办法做到对每一个人好，也没办法要求每一个人都是真心爱你。所以你要有自己的选择，与舒服的人相处，对讨厌的人远离，过你自己觉得开心自在的生活就好，没必要为了便利别人，让自己受尽委屈。

看过一段话：善良是很珍贵的，但善良要是没有长出牙齿来，那就是软弱。

你的善良，要有锋芒，不要把时间浪费在不值得的人身上。对爱你的人，倾心相助，对利用你的人，勇敢说不。

愿你的善良，能被真心的人温柔以待。

让闲置 Ubuntu 服务器华丽转身为家庭影院

在数字化的时代，家里的设备更新换代频繁，很容易就会有闲置的服务器吃灰。我家里就有一台闲置的 Ubuntu 24.04 服务器，一直放在角落，总觉得有些浪费。于是，我决定让它重新发挥作用，打造一个属于自己的家庭影院。

一、实现 Windows 与 Ubuntu 服务器文件互通

要打造家庭影院，首先得让本地 Windows 电脑和 Ubuntu 服务器之间能够方便地传输电影文件。我选择安装 Samba 来实现这一目的。

1. 安装 Samba：在 Ubuntu 服务器的终端中输入命令

   sudo apt-get install samba samba-common
   
   

   系统会自动下载并安装 Samba 相关的软件包。

2. 备份配置文件：为了以防万一，我先将原来的 Samba 配置文件进行备份，执行命令

   mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
   
   

3. 新建配置文件：使用 vim /etc/samba/smb.conf 命令打开编辑器，写入以下配置内容：

[global]

server min protocol = CORE

workgroup = WORKGR0UP

netbios name = Nas

security = user

map to guest = bad user

guest account = nobody

client min protocol = SMB2

server min protocol = SMB2

server smb encrypt = off

[NAS]

comment = NASserver

path = /home/bddxg/nas

public = Yes

browseable = Yes

writable = Yes

guest ok = Yes

passdb backend = tdbsam

create mask = 0775

directory mask = 0775

这里需要注意的是，我计划的媒体库目录是个人目录下的 nas/，所以 path 是 /home/bddxg/nas ，如果大家要部署的话记得根据自己的实际情况修改为对应的位置。 

4. 连接 Windows 电脑：在 Windows 电脑这边基本不需要什么复杂配置，因为在网络里无法直接看到 Ubuntu，我直接在电脑上添加了网络位置。假设服务器地址是 192.168.10.100，那么添加网络位置就是 \\192.168.10.100\nas，这样就可以在 Windows 电脑和 Ubuntu 服务器之间传输文件了。

二、安装 Jellyfin 搭建家庭影院

文件传输的问题解决后，接下来就是安装 Jellyfin 来实现家庭影院的功能了。

1. 尝试 Docker 安装失败：一开始我选择使用 Docker 安装，毕竟 Docker 有很多优点，使用起来也比较方便。按照官网指南进行操作，在第三步启动 Docker 并挂载本地目录的时候却一直失败。报错信息为:

   docker: Error response from daemon: error while creating mount source path '/srv/jellyfin/cache': mkdir /srv/jellyfin: read-only file system.
   
   

   即使我给 /srv/jellyfin 赋予了 777 权限也没有效果。无奈之下，我决定放弃 Docker 安装方式，直接安装 server 版本的 Jellyfin。

2. 安装 server 版本的 Jellyfin：在终端中输入命令 curl https://repo.jellyfin.org/install-debuntu.sh | sudo bash，安装过程非常顺利。

3. 配置 Jellyfin：安装完成后，通过浏览器访问 http://192.168.10.100:8096 进入配置页面。在添加媒体库这里，我遇到了一个麻烦，网页只能选择到 /home/bddxg 目录，无法继续往下选择到我的媒体库位置 /home/bddxg/nas。于是我向 deepseek 求助，它告诉我需要执行命令:

   sudo usermod -aG bddxg jellyfin
   
   # 并且重启 Jellyfin 服务
   
   sudo systemctl restart jellyfin
   
   

   按照它的建议操作后，我刷新了网页，重新配置了 Jellyfin，终于可以正常添加媒体库了。

4. 电视端播放：在电视上安装好 Jellyfin apk 客户端后，现在终于可以正常读取 Ubuntu 服务器上的影视资源了，坐在沙发上，享受着大屏观影的乐趣，这种感觉真的太棒了！

 通过这次折腾，我成功地让闲置的 Ubuntu 服务器重新焕发生机，变成了一个功能强大的家庭影院。希望我的经验能够对大家有所帮助，也欢迎大家一起交流更多关于服务器利用和家庭影院搭建的经验。

[!WARNING] 令人遗憾的是,目前 jellyfin 似乎不支持rmvb 格式的影片, 下载资源的时候注意影片格式,推荐直接下载 mp4 格式的资源

---

本次使用到的软件名称和版本如下:

软件名	版本号	安装命令
samba	Version 4.19.5-Ubuntu	sudo apt-get install samba samba-common
jellyfin	Jellyfin.Server 10.10.6.0	curl https://repo.jellyfin.org/install-debuntu.sh | sudo bash
ffmpeg(jellyfin 内自带)	ffmpeg version 7.0.2-Jellyfin	null

作者：冰冻大西瓜
来源：juejin.cn/post/7476614823883833382

在 MyBatis 中，如果 Mapper 接口的方法有多个参数，但没有使用 @Param 注解，默认情况下，MyBatis 会将这些参数放入一个 Map 中，键名为 param1、param2 等，或者使用索引 0、1 等来访问。以下是具体的使用方法和注意事项。

一、Mapper 接口方法

假设有一个 Mapper 接口方法，包含多个参数但没有使用 @Param 注解：

public interface UserMapper {

    User selectUserByNameAndAge(String name, int age);

}

二、XML 文件中的参数引用

在 XML 文件中，可以通过以下方式引用参数：

1. 使用 param1、param2 等

MyBatis 会自动为参数生成键名 param1、param2 等：

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{param1} AND age = #{param2}

</select>

2. 使用索引 0、1 等

也可以通过索引 0、1 等来引用参数：

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{0} AND age = #{1}

</select>

三、注意事项

四、示例代码

1. Mapper 接口

public interface UserMapper {

    User selectUserByNameAndAge(String name, int age);

}

2. XML 文件

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{param1} AND age = #{param2}

</select>

或者：

<select id="selectUserByNameAndAge" resultType="User">

  SELECT * FROM user WHERE name = #{0} AND age = #{1}

</select>

3. 测试代码

SqlSession sqlSession = sqlSessionFactory.openSession();

UserMapper mapper = sqlSession.getMapper(UserMapper.class);

User user = mapper.selectUserByNameAndAge("John", 25);

System.out.println(user);

sqlSession.close();

• 如果 Mapper 接口方法有多个参数且没有使用 @Param 注解，可以通过 param1、param2 或索引 0、1 等方式引用参数。


• 这种方式可读性较差，容易出错，推荐使用 @Param 注解明确参数名称。


• 使用 @Param 注解后，XML 文件中的参数引用会更加清晰和易于维护。

作为Java后端开发者转向游戏后端开发，虽然核心编程能力相通，但游戏开发在架构设计、协议选择、实时性处理等方面有显著差异。以下从实际工作流程角度详细说明游戏后端开发的核心要点及前后端协作流程：

一、游戏后端核心职责

二、开发全流程实战（以MMORPG为例）

阶段1：预研设计（2-4周）

• 协议设计
  

  // 使用Protobuf定义移动协议
  
  message PlayerMove {
  
    int32 player_id = 1;
  
    Vector3 position = 2;  // 三维坐标
  
    float rotation = 3;    // 朝向
  
    int64 timestamp = 4;   // 客户端时间戳
  
  }
  
  
  
  message BattleSkill {
  
    int32 skill_id = 1;
  
    repeated int32 target_ids = 2;  // 多目标锁定
  
    Coordinate cast_position = 3;   // 技能释放位置
  
  }
  
  

  
  


• 架构设计
  

  graph TD
  
    A[Gateway] --> B[BattleServer]
  
    A --> C[SocialServer]
  
    B --> D[RedisCluster]
  
    C --> E[MySQLCluster]
  
    F[MatchService] --> B
  
  

  
  

阶段2：核心系统开发（6-8周）

三、前后端协作关键点

四、性能优化实践

五、上线后运维

六、常见问题解决方案

问题场景：战斗不同步

排查步骤：

问题场景：登录排队

优化方案：

通过以上流程，Java后端开发者可逐步掌握游戏开发特性，重点需要转变的思维模式包括：从请求响应模式到实时状态同步、从CRUD主导到复杂逻辑计算、从分钟级延迟到毫秒级响应的要求。建议从简单的棋牌类游戏入手，逐步过渡到大型实时游戏开发。

大家好，我是 Java陈序员。

由于为了生活奔波，常年在外，导致很多关系稍疏远的亲戚之间来往并不多。

因此节假日回家时，往往会搞不清楚哪位亲戚应该喊什么称呼，很容易“社死”。

今天给大家介绍一个亲戚关系计算器，让你快速的计算出正确的亲戚称谓！

关注微信公众号：【Java陈序员】，获取开源项目分享、AI副业分享、超200本经典计算机电子书籍等。

项目介绍

relationship —— 中国亲戚关系计算器，只需简单的输入即可算出称谓。

输入框兼容了不同的叫法，你可以称呼父亲为：“老爸”、“爹地”、“老爷子”等等，方便不同地域的习惯叫法。

快捷输入按键，只需简单的点击即可完成关系输入，算法还支持逆向查找称呼哦～

功能特色：

• 使用别称查询：姥姥的爸爸的老窦 = 外曾外曾祖父


• 使用合称查询：姐夫的双亲 = 姊妹姻父 / 姊妹姻母


• 大小数字混合查询：大哥的二姑妈的七舅姥爷 = 舅曾外祖父


• 不限制祖辈孙辈跨度查询：舅妈的婆婆的外甥的姨妈的侄子 = 舅表舅父


• 根据年龄推导可能性：哥哥的表姐 = 姑表姐 / 舅表姐


• 根据语境确认性别：老婆的女儿的外婆 = 岳母


• 支持古文式表达：吾父之舅父 = 舅爷爷


• 解析某称谓关系链：七舅姥爷 = 妈妈的妈妈的兄弟


• 算两个亲戚间的合称关系：奶奶 + 外婆 = 儿女亲家

项目地址：

https://github.com/mumuy/relationship

在线体验：

https://passer-by.com/relationship/

移动端体验地址：

https://passer-by.com/relationship/vue/

功能体验

1、关系找称呼

2、称呼找关系

3、两者间关系

4、两者的合称

安装使用

1、直接引入安装

<script src="https://passer-by.com/relationship/dist/relationship.min.js">

获取全局方法 relationship.

2、使用 npm 包管理安装

安装依赖：

npm install relationship.js

包引入：

// CommonJS 引入

const relationship = require("relationship.js");

// ES Module 引入

import relationship from 'relationship.js';

3、使用方法：唯一的计算方法 relationship.

• 选项模式 relationship(options)
  
  

  构造函数：

  
  

  var options = {
  
      text:'',		// 目标对象：目标对象的称谓汉字表达，称谓间用‘的’字分隔
  
      target:'',	    // 相对对象：相对对象的称谓汉字表达，称谓间用‘的’字分隔，空表示自己
  
      sex:-1,			// 本人性别：0表示女性,1表示男性
  
      type:'default',	// 转换类型：'default'计算称谓,'chain'计算关系链,'pair'计算关系合称
  
      reverse:false,	// 称呼方式：true对方称呼我,false我称呼对方
  
      mode:'default',	// 模式选择：使用setMode方法定制不同地区模式，在此选择自定义模式
  
      optimal:false,  // 最短关系：计算两者之间的最短关系
  
  };
  
  

  
  

  代码示例：

  
  

  // 如：我应该叫外婆的哥哥什么？
  
  relationship({text:'妈妈的妈妈的哥哥'});
  
  // => ['舅外公']
  
  
  
  // 如：七舅姥爷应该叫我什么？
  
  relationship({text:'七舅姥爷',reverse:true,sex:1});
  
  // => ['甥外孙']
  
  
  
  // 如：舅公是什么亲戚
  
  relationship({text:'舅公',type:'chain'});
  
  // => ['爸爸的妈妈的兄弟', '妈妈的妈妈的兄弟', '老公的妈妈的兄弟']
  
  
  
  // 如：舅妈如何称呼外婆？
  
  relationship({text:'外婆',target:'舅妈',sex:1});
  
  // => ['婆婆']
  
  
  
  // 如：外婆和奶奶之间是什么关系？
  
  relationship({text:'外婆',target:'奶奶',type:'pair'});
  
  // => ['儿女亲家']
  
  

  
  


• 语句模式 relationship(exptession)
  
  

  
  

  参数 exptession 句式可以为：xxx是xxx的什么人、xxx叫xxx什么、xxx如何称呼xxx等。

  
  

  
  

  代码示例：

  
  

  // 如：舅妈如何称呼外婆？
  
  relationship('舅妈如何称呼外婆？');
  
  // => ['婆婆']
  
  
  
  // 如：外婆和奶奶之间是什么关系？
  
  relationship('外婆和奶奶之间是什么关系？');
  
  // => ['儿女亲家']
  
  

  
  

4、其他 API

// 获取当前数据表 

relationship.data



// 获取当前数据量 

relationship.dataCount



// 用户自定义模式 

relationship.setMode(mode_name,mode_data)

最后

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

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

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

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

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

前言

在家没事的时候刷抖音玩，抖音首页的视频怎么刷也刷不完，经常不知不觉的一刷就到半夜了😅

不禁感叹道 ＂垃圾抖音，费我时间，毁我青春😅＂

这是我的 模仿抖音 系列文章的第二篇，本文将一步步实现抖音首页 视频无限滑动 的效果，干货满满

第一篇：200行代码实现类似Swiper.js的轮播组件

第三篇：Vue 路由使用介绍以及添加转场动画

第四篇：Vue 有条件路由缓存，就像传统新闻网站一样

第五篇：Github Actions 部署 Pages、同步到 Gitee、翻译 README 、 打包 docker 镜像

如果您对滑动原理不太熟悉，推荐先看我的这篇文章：200行代码实现类似Swiper.js的轮播组件

最终效果

在线预览：dy.ttentau.top/

Github地址：github.com/zyronon/dou…

源码：SlideVerticalInfinite.vue

实现原理

无限滑动的原理和虚拟滚动的原理差不多，要保持 SlideList 里面永远只有 N 个 SlideItem，就要在滑动时不断的删除和增加 SlideItem。

滑动时调整 SlideList 的偏移量 translateY 的值，以及列表里那几个 SlideItem 的 top 值，就可以了

为什么要调整 SlideList 的偏移量 translateY 的值同时还要调整 SlideItem 的 top 值呢？

因为 translateY 只是将整个列表移动，如果我们列表里面的元素是固定的，不会变多和减少，那么没关系，只调整　translateY 值就可以了，上滑了几页就减几页的高度，下滑同理

但是如果整个列表向前移动了一页，同时前面的 SlideItem 也少了一个，，那么最终效果就是移动了两页...因为 塌陷 了一页

这显然不是我们想要的，所以我们还需要同时调整 SlideItem 的 top 值，加上前面少的 SlideItem 的高度，这样才能显示出正常的内容

步骤

定义

virtualTotal：页面中同时存在多少个 SlideItem，默认为 5。

//页面中同时存在多少个SlideItem

virtualTotal: {

  type: Number,

  default: () => 5

},

设置这个值可以让外部组件使用时传入，毕竟每个人的需求不同，有的要求同时存在 10 条，有的要求同时存在 5 条即可。

不过同时存在的数量越大，使用体验就越好，即使用户快速滑动，我们依然有时间处理。

如果只同时存在 5 条，用户只需要快速滑动两次就到底了(因为屏幕中显示第 3 条，刚开始除外)，我们可能来不及添加新的视频到最后

render：渲染函数，SlideItem内显示什么由render返回值决定

render: {

  type: Function,

  default: () => {

    return null

  }

},

之所以要设定这个值，是因为抖音首页可不只有视频，还有图集、推荐用户、广告等内容，所以我们不能写死显示视频。

最好是定义一个方法，外部去实现，我们内部去调用，拿到返回值，添加到 SlideList 中

list：数据列表，外部传入

list: {

  type: Array,

  default: () => {

    return []

  }

},

我们从 list 中取出数据，然后调用并传给 render 函数，将其返回值插入到 SlideList中

初始化

watch(

  () => props.list,

  (newVal, oldVal) => {

    //新数据长度比老数据长度小，说明是刷新

    if (newVal.length < oldVal.length) {

      //从list中取出数据，然后调用并传给render函数，将其返回值插入到SlideList中

      insertContent()

    } else {

      //没数据就直接插入

      if (oldVal.length === 0) {

        insertContent()

      } else {

        // 走到这里，说明是通过接口加载了下一页的数据，

        // 为了在用户快速滑动时，无需频繁等待请求接口加载数据，给用户更好的使用体验

        // 这里额外加载3条数据。所以此刻，html里面有原本的5个加新增的3个，一共8个dom

        // 用户往下滑动时只删除前面多余的dom，等滑动到临界值（virtualTotal/2+1）时，再去执行新增逻辑

      }

    }

  }

)

用 watch 监听 list 是因为它一开始不一定有值，通过接口请求之后才有值

同时当我们下滑 加载更多 时，也会触发接口请求新的数据，用 watch 可以在有新数据时，多添加几条到 SlideList 的最后面，这样用户快速滑动也不怕了

如何滑动

这里就不再赘述，参考我的这篇文章：200行代码实现类似Swiper.js的轮播组件

滑动结束

判断滑动的方向

当我们向上滑动时,需要删除最前面的 dom ，然后在最后面添加一个 dom

下滑时反之

slideTouchEnd(e, state, canNext, (isNext) => {

  if (props.list.length > props.virtualTotal) {

    //手指往上滑(即列表展示下一条视频)

    if (isNext) {

      //删除最前面的 `dom` ，然后在最后面添加一个 `dom`  

    } else {

      //删除最后面的 `dom` ，然后在最前面添加一个 `dom`  

    }

  }

})

手指往上滑(即列表展示下一条视频)

• 首先判断是否要加载更多，快到列表末尾时就要加载更多数据了


• 再判断是否符合 腾挪 的条件，即当前位置要大于 half，且小于列表长度减 half。


• 在最后面添加一个 dom


• 删除最前面的 dom


• 将所有 dom 设置为最新的 top 值(原因前面有讲，因为删除了最前面的 dom，导致塌陷一页，所以要加上删除 dom 的高度)

let half = (props.virtualTotal - 1) / 2



//删除最前面的 `dom` ，然后在最后面添加一个 `dom`  

if (state.localIndex > props.list.length - props.virtualTotal && state.localIndex > half) {

  emit('loadMore')

}



//是否符合 `腾挪` 的条件

if (state.localIndex > half && state.localIndex < props.list.length - half) {

  //在最后面添加一个 `dom`  

  let addItemIndex = state.localIndex + half

  let res = slideListEl.value.querySelector(`.${itemClassName}[data-index='${addItemIndex}']`)

  if (!res) {

    slideListEl.value.appendChild(getInsEl(props.list[addItemIndex], addItemIndex))

  }



  //删除最前面的 `dom` 

  let index = slideListEl.value

    .querySelector(`.${itemClassName}:first-child`)

    .getAttribute('data-index')

  appInsMap.get(Number(index)).unmount()



  slideListEl.value.querySelectorAll(`.${itemClassName}`).forEach((item) => {

    _css(item, 'top', (state.localIndex - half) * state.wrapper.height)

  })

}

手指往下滑(即列表展示上一条视频)

逻辑和上滑都差不多，不过是反着来而已

• 再判断是否符合 腾挪 的条件，和上面反着


• 在最前面添加一个 dom


• 删除最后面的 dom


• 将所有 dom 设置为最新的 top 值

//删除最后面的 `dom` ，然后在最前面添加一个 `dom`

if (state.localIndex >= half && state.localIndex < props.list.length - (half + 1)) {

  let addIndex = state.localIndex - half

  if (addIndex >= 0) {

    let res = slideListEl.value.querySelector(`.${itemClassName}[data-index='${addIndex}']`)

    if (!res) {

      slideListEl.value.prepend(getInsEl(props.list[addIndex], addIndex))

    }

  }

  let index = slideListEl.value

    .querySelector(`.${itemClassName}:last-child`)

    .getAttribute('data-index')

  appInsMap.get(Number(index)).unmount()



  slideListEl.value.querySelectorAll(`.${itemClassName}`).forEach((item) => {

    _css(item, 'top', (state.localIndex - half) * state.wrapper.height)

  })

}

其他问题

为什么不直接用 v-for直接生成 SlideItem 呢?

如果内容不是视频就可以。要删除或者新增时，直接操作 list 数据源，这样省事多了

如果内容是视频，修改 list 时，Vue 会快速的替换 dom，正在播放的视频，突然一下从头开始播放了😅😅😅

如何获取 Vue 组件的最终 dom

有两种方式，各有利弊

• 用 Vue 的 render 方法
  
  
  
  • 优点：只是渲染一个 VNode 而已，理论上讲内存消耗更少。
  
  
  • 缺点：但我在开发中，用了这个方法，任何修改都会刷新页面，有点难蚌😅
  
  
  
  


• 用 Vue 的 createApp 方法再创建一个 Vue 的实例
  
  
  
  • 和上面相反😅
  
  
  
  

import { createApp, onMounted, reactive, ref, render as vueRender, watch } from 'vue'



/**

 * 获取Vue组件渲染之后的dom元素

 * @param item

 * @param index

 * @param play

 */

function getInsEl(item, index, play = false) {

  // console.log('index', cloneDeep(item), index, play)

  let slideVNode = props.render(item, index, play, props.uniqueId)

  const parent = document.createElement('div')

  //TODO 打包到线上时用这个，这个在开发时任何修改都会刷新页面

  if (import.meta.env.PROD) {

    parent.classList.add('slide-item')

    parent.setAttribute('data-index', index)

    //将Vue组件渲染到一个div上

    vueRender(slideVNode, parent)

    appInsMap.set(index, {

      unmount: () => {

        vueRender(null, parent)

        parent.remove()

      }

    })

    return parent

  } else {

    //创建一个新的Vue实例，并挂载到一个div上

    const app = createApp({

      render() {

        return <SlideItem data-index={index}>{slideVNode}</SlideItem>

      }

    })

    const ins = app.mount(parent)

    appInsMap.set(index, app)

    return ins.$el

  }

}