随着小程序项目的不断迭代升级，避免不了体积越来越大。微信限制主包最多2M，然而我们的项目引入了直播插件直接占了1.1M，导致必须采用一些手段去优化。下面介绍一下优化思路和终极解决方案。

1.分包

我相信几乎所有人都能想到的方案，基本上这个方案就能解决问题。具体如何实现可以参照官方文档这里不做过多说明。(基础能力 / 分包加载 / 使用分包 (qq.com))，但是有时候你会发现分包之后好像主包变化不是很大，这是为什么呢？

• 痛点1：通过依赖分析，如果分包中引入了第三方依赖，那么依赖的js仍然会打包在主包中，例如echarts、wxparse、socket.io。这就导致我们即使做了分包处理，但是主包还是很大，因为相关的js都会在主包中的vendor.js


• 痛点2：插件只能在主包中无法分包，例如直播插件直接占据1M
  


• 痛点3：tabbar页面无法分包，只能在主包内


• 痛点4：公共组件/方法无法分包，只能在主包内


• 痛点5：图片只能在主包内

2.图片优化

图片是最好解决的，除了tabbar用到的图标，其余都放在云上就好了，例如oss和obs。而且放在云上还有个好处就是背景图片无需担心引入不成功。

3.tabbar页面优化

这部分可以采用tabbar页面都在放在一个文件夹下，比如一共有4个tab，那么一个文件夹下就只存放这4个页面。其余tabbar的子页面一律采用分包。

4.独立分包

独立分包是小程序中一种特殊类型的分包，可以独立于主包和其他分包运行。从独立分包中页面进入小程序时，不需要下载主包。当用户进入普通分包或主包内页面时，主包才会被下载。
但是使用的时候需要注意：

• 独立分包中不能依赖主包和其他分包中的内容，包括 js 文件、template、wxss、自定义组件、插件等（使用 分包异步化 时 js 文件、自定义组件、插件不受此条限制）


• 主包中的 app.wxss 对独立分包无效，应避免在独立分包页面中使用 app.wxss 中的样式；


• App 只能在主包内定义，独立分包中不能定义 App，会造成无法预期的行为；


• 独立分包中暂时不支持使用插件。

5.终极方案we-script

我们自己写的代码就算再多，其实增加的kb并不大。大部分大文件主要源于第三方依赖，那么有没有办法像webpack中的externals一样，当进入这个页面的时候再去异步加载js文件而不被打包呢（说白了就是CDN）

其实解决方案就是we-script，他允许我们使用CDN方式加载js文件。这样就不会影响打包体积了。

使用步骤

使用中存在的坑

构建后可能会出现依赖报错，解决的方式就是将编译好的文件手动拖入miniprogram_npm文件夹中，主要是三个文件夹：we-script,acorn,eval5

最后成功解决了主包文件过大的问题，只要是第三方依赖，都可以通过这个办法去加载。

感谢阅读，希望来个三连支持下，转载记得标注原文地址~

前言

作为一个 uniapp 初学者，恰巧遇到微信短剧播放器接入的需求，在网上检索许久并没有发现傻瓜式教程。于是总结 uni-app 官网文档及微信开放文档，自行实践后，总结出几个步骤，希望为大家提供些帮助。实践后发现其实确实比较简单，大佬们可能也懒得写文档，那么就由我这个小白大概总结下。本文档仅涉及剧目提审成功后的播放器接入，其余相关问题请参考微信官方文档。

小程序申请插件

参考文档：developers.weixin.qq.com/miniprogram…

首先，需要在小程序后台，申请 appid 为 wx94a6522b1d640c3b 的微信插件，可以在微信小程序管理后台进行添加，路径是 设置 - 第三方设置 - 插件管理 - 添加插件，搜索 wx94a6522b1d640c3b 后进行添加：

uni-app 项目添加微信插件

参考文档：uniapp.dcloud.net.cn/tutorial/mp…

添加插件完成后，在 manifest.json 中，点击 源码视图，找到如下位置并添加红框内的代码，此步骤意在将微信小程序插件引入项目。

/* 添加微短剧播放器插件 */

 "plugins" : {

    "playlet-plugin" : {

         "version" : "latest",

         "provider" : "wx94a6522b1d640c3b"

     }

 }

manifest.json 中完成添加后，需要在 pages.json 中找一个页面（我这边使用的是一个新建的空白页面）挂载组件，挂载方式如下图红框中所示，需注意，这里的组件名称需要与 manifest.json 中定义的一致：

{

	"path": "newPage/newPage",

	"style": {

		"navigationBarTitleText": "",

		"enablePullDownRefresh": false,

		"navigationStyle": "custom",

		"app-plus": {

			"bounce": "none"

		},

		"mp-weixin": {

			"usingComponents": {

				"playlet-plugin": "plugin://playlet-plugin/playlet-plugin"

			}

		}

	}

}

挂载空页面是个笨办法，目前我这边尝试如果不挂载的话，会有些问题，有大神知道别的方法可以在评论区指点一下～

App.vue 配置

参考文档：developers.weixin.qq.com/miniprogram…

首先，找个地方新建一个 playerManager.js，我这边建在了 common 文件夹下。代码如下（代码参考微信官方文档给出的 demo）：

	var plugin = requirePlugin("playlet-plugin");

	// 点击按钮触发此函数跳转到播放器页面

	function navigateToPlayer(obj) {

	    // 下面的${dramaId}变量,需要替换成小程序管理后台的媒资管理上传的剧目的dramaId，变量${srcAppid}是提审方appid，变量${serialNo}是某一集，变量${extParam}是扩展字段，可通过

	    const { extParam, dramaId, srcAppid, serialNo } = obj

	    wx.navigateTo({

	      url: `plugin-private://wx94a6522b1d640c3b/pages/playlet/playlet?dramaId=${dramaId}&srcAppid=${srcAppid}&serialNo=${serialNo}&extParam=${extParam || ''}`

	    })

	}

	const proto = {

	  _onPlayerLoad(info) {

	    const pm = plugin.PlayletManager.getPageManager(info.playerId)

	    this.pm = pm

	    // encryptedData是经过开发者后台加密后(不要在前端加密)的数据，具体实现见下面的加密章节

	    this.getEncryptData({serialNo: info.serialNo}).then(res => {

	      // encryptedData是后台加密后的数据，具体实现见下面的加密章节

	      pm.setCanPlaySerialList({

	        data: res.encryptedData,

	        freeList: [{start_serial_no: 1, end_serial_no: 10}], // 1~10集是免费剧集

	      })

	    })

	    pm.onCheckIsCanPlay(this.onCheckIsCanPlay)

	    // 关于分享的处理

	    // 开启分享以及withShareTicket

	    pm.setDramaFlag({

	      share: true,

	      withShareTicket: true

	    })

	    // 获取分享参数,页面栈只有短剧播放器一个页面的时候可获取到此参数

	    // 例如从分享卡片进入、从投流广告直接跳转到播放器页面，从二维码直接进入播放器页面等情况

	    plugin.getShareParams().then(res => {

	      console.log('getLaunch options query res', res)

	      // 关于extParam的处理，需要先做decodeURIComponent之后才能得到原值

	      const extParam = decodeURIComponent(res.extParam)

	      console.log('getLaunch options extParam', extParam)

	      // 如果设置了withShareTicket为true，可通过文档的方法获取更多信息

	      // https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/share.html

	      const enterOptions = wx.getEnterOptionsSync()

	      console.log('getLaunch options shareTicket', enterOptions.shareTicket)

	    }).catch(err => {

	      console.log('getLaunch options query err', err)

	    })

	    // extParam除了可以通过在path传参，还可以通过下面的接口设置

	    pm.setExtParam('hellotest')

	    // 分享部分end

	  },

	  onCheckIsCanPlay(param) {

	    // TODO: 碰到不可以解锁的剧集，会触发此事件，这里可以进行扣币解锁逻辑，如果用户无足够的币，可调用下面的this.isCanPlay设置

	    console.log('onCheckIsCanPlay param', param)

	    var serialNo = param.serialNo

	    this.getEncryptData({serialNo: serialNo}).then(res => {

	      // encryptedData是后台加密后的数据，具体实现见下面的加密章节

	      this.pm.isCanPlay({

	        data: res.encryptedData,

	        serialNo: serialNo,

	      })

	    })

	  },

	  getEncryptData(obj) {

	    const { serialNo } = obj

	    // TODO: 此接口请求后台，返回下面的setCanPlaySerialList接口需要的加密参数

	    const { srcAppid, dramaId } = this.pm.getInfo()

	    console.log('getEncryptData start', srcAppid, dramaId, serialNo)

	    return new Promise((resolve, reject) => {

	      resolve({

	        encryptedData: '' // TODO: 此参数需从后台接口获取到

	      })

	    })

	  },

	}

	function PlayerManager() {

	  var newProto = Object.assign({}, proto)

	  for (const k in newProto) {

	    if (typeof newProto[k] === 'function') {

	      this[k] = newProto[k].bind(this)

	    }

	  }

	}

	

	PlayerManager.navigateToPlayer = navigateToPlayer

	module.exports = PlayerManager

新建完成后，在 App.vue 中进行组件的配置和引用。

onLaunch: function() {

	// playlet-plugin必须和上面的app.json里面声明的插件名称一致

	const playletPlugin = requirePlugin('playlet-plugin')

	

	const _onPlayerLoad = (info) => {

		var PlayerManager = require('@/common/playerManager.js')

		const playerManager = new PlayerManager()

		playerManager._onPlayerLoad(info)

	}

	// 注册播放器页面的onLoad事件

	playletPlugin.onPageLoad(_onPlayerLoad.bind(this))

},

_onPlayerLoad(info) {

	var PlayerManager = require('@/common/playerManager.js')

    const playerManager = new PlayerManager()

    playerManager._onPlayerLoad(info)

},

页面使用

参考文档：developers.weixin.qq.com/miniprogram…

以上所有步骤完成后，就可以开心的使用短剧播放器了。 我这边临时写了个图片的 click 事件测试了一下：

clk() {

	// 逻辑处理...获取你的各种参数

	// 打开组件中封装的播放器页面

	PlayerManager.navigateToPlayer({

		srcAppid: 'wx1234567890123456', // 剧目提审方 appid

		dramaId: '100001', // 小程序管理后台的媒资管理上传的剧目的 dramaId

		serialNo: '1', // 剧目中的某一集

		extParam: encodeURIComponent('a=b&c=d'), // 扩展字段,需要encode

	})

},

写在最后：

总结完了，其实整体下来不是很难，对我这种前端小白来说检索和整合的过程是比较痛苦的，所以希望下一个接入的朋友可以少检索一些文档吧。
另附一个短剧播放器接口的文档： developers.weixin.qq.com/miniprogram…
文档主要介绍了短剧播放器插件提供的几个接口，在js代码里，插件接口实例通过下面的代码获取

// 名字playlet-plugin必须和app.json里面引用的插件名一致

const playletPlugin = requirePlugin('playlet-plugin')

读书越多越发现自己的无知，Keep Fighting！

欢迎友善交流，不喜勿喷~

Hope can help~

😅【现场还原】

"前端为什么没有自己的数据库？把数据存前端不就解决了后端性能问题" ——当CTO抛出这个灵魂拷问时，会议室突然安静得能听见CPU风扇的嗡鸣，在座所有人都无语了。这场因后端性能瓶颈引发的技术博弈，最终以"前端分页查询+本地筛选"的妥协方案告终。

面对现在几乎所有公司的技术leader都是后端出身，有的不懂前端甚至不懂技术，作为前端开发者，我们真的只能被动接受吗？

😣【事情背景】

• 需求：前端展示所有文章的标签列表，用户可以选择标签筛选文章，支持多选，每个文章可能有多个标签，也可能没任何标签。


• 前端观点：针对这种需求，我自然想到用户选中标签后，将标签id传给后端，后端根据id筛选文章列表返回即可。


• 后端观点：后端数据分库分表，根据标签检索数据还要排序分页，有性能瓶颈会很慢，很慢就会导致天天告警。


• 上升决策：由于方案有上述分歧，我们就找来了双方leader决策，双方leader也有分歧，最终叫来了CTO。领导想让我们将数据定时备份到前端，需要筛选的时候前端自己筛选。
  
  

  
  

  CTO语录：

  
  

  “前端为什么没有数据库？，把数据存前端，前端筛选，数据库不就没有性能压力了”

  
  

  "现在手机性能比服务器还强，让前端存全量数据怎么了？"

  
  

  "IndexedDB不是数据库？localStorage不能存JSON？"

  
  

  "分页？让前端自己遍历数组啊，这不就是你们说的'前端工程化'吗？"

  
  

  
  

😓【折中方案】

在方案评审会上，我们据理力争：

但现实往往比代码更复杂——当CTO拍板要求"先实现再优化"，使用了奇葩的折中方案：

• 前端轮询获取前1000条数据做本地筛选，用户分页获取数据超过1000条后，前端再轮询获取1000条，以此类推。


• 前端每页最多获取50条数据，每次最多并发5个请求（后端要求）

只要技术监控不报错，至于用户体验？慢慢等着吧你......

🖨️【批量并发请求】

既然每页只有50条数据，那我至少得发20个请求来拿到所有数据。显然，逐个请求会让用户等待很长时间，明显不符合前端性能优化的原则。于是我选择了 p-limit 和Promise.all来实现异步并发线程池。通过并发发送多个请求，可以大大减少数据获取的总时间。

import pLimit from 'p-limit';

const limit = pLimit(5); // 限制最多5个并发请求



// 模拟接口请求

const fetchData = (page, pageSize) => {

  return new Promise((resolve) => {

    setTimeout(() => {

      resolve(`数据页 ${page}：${pageSize}条数据`);

    }, 1000);

  });

};



// 异步任务池

const runTasks = async () => {

  const totalData = 1000;  // 总数据量

  const pageSize = 50;     // 每页容量



  const totalPages = Math.ceil(totalData / pageSize); // 计算需要多少页



  const tasks = [];

  

  // 根据总页数动态创建请求任务

  for (let i = 1; i <= totalPages; i++) {

    tasks.push(limit(() => fetchData(i, pageSize))); // 使用pLimit限制并发请求

  }

  

  const results = await Promise.all(tasks); // 等待所有请求完成

  console.log('已完成所有任务:', results);

};



runTasks();

📑【高效本地筛选数据】

当所有数据都请求回来了，下一步就是进行本地筛选。毕竟后端已经将查询任务分配给了前端，所以我得尽可能让筛选的过程更高效，避免在本地做大量的计算导致性能问题。

1. 使用哈希进行高效查找

如果需要根据某个标签来筛选数据，最直接的做法就是遍历整个数据集，但这显然效率不高。于是我决定使用哈希表（或 Map）来组织数据。这样可以在常数时间内完成筛选操作。

const filterDataByTag = (data, tag) => {

  const tagMap = new Map();



  data.forEach(item => {

    if (!tagMap.has(item.tag)) {

      tagMap.set(item.tag, []);

    }

    tagMap.get(item.tag).push(item);

  });



  return tagMap.get(tag) || [];

};



const result = filterDataByTag(allData, 'someTag');

console.log(result);

2. 使用 Web Workers 进行数据处理

如果数据量很大，筛选过程可能会比较耗时，导致页面卡顿。为了避免这个问题，可以将数据筛选的过程交给 Web Workers 处理。Web Worker 可以在后台线程运行，避免阻塞主线程，从而让用户体验更加流畅。

const worker = new Worker('worker.js');



worker.postMessage(allData);



worker.onmessage = function(event) {

  const filteredData = event.data;

  console.log('筛选后的数据:', filteredData);

};



// worker.js

onmessage = function(e) {

  const data = e.data;

  const filteredData = data.filter(item => item.tag === 'someTag');

  postMessage(filteredData);

};

📝【总结】

这场技术博弈给我们带来三点深刻启示：

站在CTO那句"前端为什么没有数据库"的肩膀上，我们正在构建这样的未来：每个前端应用都内置轻量级数据库内核，通过差异同步策略与后端保持数据一致，利用浏览器计算资源实现真正的端智能。这不是妥协的终点，而是下一代Web应用革命的起点。

后记：三个月后，我们基于SQL.js实现了前端SQL查询引擎，配合WebWorker线程池，使得复杂筛选的耗时从秒级降至毫秒级——但这已经是另一个技术突围的故事了。

前言

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

有趣的动画效果

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

那么在 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多名前端小伙伴在等着一起学习哦 --> 摸鱼沸点

俗话说得好：“程序员宁愿写 1000 行代码，也不愿意写 10 个字的文档。”

不愿写文档的原因，一方面是咱理科生文采确实不好，另一方面则是文档的更新维护十分麻烦。

每次功能有变更的时候， 时间又急（其实就是懒），很难想得起来同时去更新文档。

特别是文档中代码片段，总是在几天之后（甚至更久），被用户找过来吐槽：“你们也太不专业了，文档里的代码都跑不通。”

作为有素养的程序员，被人说 “不专业”，简直不能忍，一定要想办法解决这个问题。

文档代码化

很多开发者喜欢用语雀，飞书或者钉钉来写文档。

不得不承认，它们的编写和阅读的体验更好，样式也更丰富。

甚至就算是版本管理，语雀，飞书做得也不比 git 差。

不过对于开发者文档，我觉得体验，样式都不是最重要的。毕竟这些都是锦上添花。

更重要的是，文档内容有效性的保证，如果文档上的代码直接复制到本地，都要调试半天才能跑通，那不管它样式再好看开发者都要骂娘了。

所以文档最好就和代码放在同一个仓库中，这样代码功能有更新时，顺便就把文档一起改了。团队前辈 Review 代码时，也能顺便关注下相关的文档是否一同更新。

如果真的一定要搞一个语雀文档，也可以考虑用 Git Action，在分支合并到 master 时触发一次文档到语雀的自动同步。

Markdown 的问题

程序员最常用的代码化文档就是 Markdown 了，估计也是很多开发者的首选，比如我这篇文章就是用 Markdown 写的。

不过 Markdown 文档中的代码示例，也没有经过单元测试的验证，还是会出现文档中代码跑不通的现象。

Python 中有一个叫做 doctest 的工具，能够抽取文档中的所有 python 代码并执行，我们只要在分支合并前，确保被合并分支同时通过了单元测试和 doctest，就能保证文档中的代码示例都是有效的。

在 Java 中我找了半天没有找到类似工具，很多语言（比如 Go， Rust 等等）据我所知也没有类似的工具。

而且对于 Java，文档中给的一般都是不完整的代码片段，无法像 Python 一样直接就能进入命令行执行。

有句俗话 ”单元测试就是最好的文档“。我觉得没必要将单元测试和文档分开，最好的方式就是从单元测试中直接引用部分代码进入文档。

在变更功能时，我们一定也会改单元测试，文档也会同步更新，不需要单独维护。

在合并分支或者发布版本之前，肯定也会有代码门禁执行单元测试，这样就能确保文档中代码示例都是有效的。

目前我发现了一个能解决该问题的方案就是 adoc 文档。

adoc 文档

adoc 的全称是 Asciidoctor， 官网链接。

Github 已经对其实现了原生支持，只要在项目中将 README 文件的后缀改成 README.adoc，Github 就会按照 adoc 的语法进行解析展示。

adoc 最强悍的能力就是可以对另一个文件的一部分进行引用。以我负责的开源项目 QLExpress 为例。

在单元测试 Express4RunnerTest 中，用 // tag::firstQl[] 和 // end::firstQl[] 圈出一个代码片段：

// import 语句省略...



/**

 * Author: DQinYuan

 */

public class Express4RunnerTest {

    // 省略...



    @Test

    public void docQuickStartTest() {

        // tag::firstQl[]

        Express4Runner express4Runner = new Express4Runner(InitOptions.DEFAULT_OPTIONS);

        Map<String, Object> context = new HashMap<>();

        context.put("a", 1);

        context.put("b", 2);

        context.put("c", 3);

        Object result = express4Runner.execute("a + b * c", context, QLOptions.DEFAULT_OPTIONS);

        assertEquals(7, result);

        // end::firstQl[]

    }





    // 省略...

}

然后在文档 README-source.adoc 中就可以 firstQl 这个 tag 引用代码片段：

=== 第一个 QLExpress 程序



[source,java,indent=0]

----

include::./src/test/java/com/alibaba/qlexpress4/Express4RunnerTest.java[tag=firstQl]

----

include::./src/test/java/com/alibaba/qlexpress4/Express4RunnerTest.java[tag=firstQl] 用于引用 Express4RunnerTest 文件中被 firstQl tag 包围的代码片段，其他的部分，等价于 Markdown 下面的写法：

### 第一个 QLExpress 程序



```java

```

这个 adoc 文档在渲染后，就会用单测中真实的代码片段替换掉 include 所占的位置，如下：

缺点就是 adoc 的语法和 Markdown 相差还挺大的，对以前用 Markdown 写文档的程序员有一定的熟悉成本。但是现在有 AI 啊，我们可以先用 Markdown 把文档写好，交给 Kimi 把它翻译成 Markdown。我对 adoc 的古怪语法也不是很熟悉，并且项目以前的文档都是 Markdown 写，都是 AI 帮我翻译的。

Github 渲染 adoc 文档的坑

我最开始尝试在 Github 上用 README.adoc 代替 README.md，发现其中的 include 语法并没有生效：

Github 对于 adoc include的渲染逻辑还挺诡异的，既不展示引用文件的内容，也没有原样展示 adoc 代码

查询资料发现 Github 根本不支持 adoc 的 include 语法的渲染（参考）。不过好在参考文档中也给了解决方案：

• 源码中用 README-source.adoc 编写文档


• 使用 Git Action 监听 README-source.adoc 文件的变化。如果有变动，则使用 asciidoctor 提供的命令行工具先预处理一下 include 语法，将引用的内容都先引用进来。再将预处理的后的内容更新到 README.adoc 中，这样 README.adoc 就都是 Github 支持的语法了，可以直接在 Github 页面上渲染

Github Action 的参考配置如下（QLExpress中的配置文件）：

name: Reduce Adoc

on:

  push:

    paths:

      - README-source.adoc

    branches: ['**']

jobs:

  build:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout Repository

        uses: actions/checkout@v3

      - name: Install Asciidoctor Reducer

        run: sudo gem install asciidoctor-reducer

      - name: Reduce README

        # to preserve preprocessor conditionals, add the --preserve-conditionals option

        run: asciidoctor-reducer --preserve-conditionals -o README.adoc README-source.adoc

      - name: Commit and Push README

        uses: EndBug/add-and-commit@v9

        with:

          add: README.adoc

添加这个配置后，你会发现很多额外的 Commit，就是 Git Action 在预处理 README-source.adoc 后，对 README.adoc 发起的提交：

至此，就再也不用担心被人吐槽文档不专业啦。

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…

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