写在前面

蜜罐就是一种通过模拟真实环境来诱导入侵者的一种技术。通过它可以拖延黑客入侵时间，递给黑客用于取证假数据，溯源黑客等。通过控制平台去操作部署的仿真环境实现高效的诱捕。

之前写过一个简单的仿真redis蜜罐，简单介绍一下。

RESP

搭建这种组件的仿真环境，要么用真实的程序，要么就自己实现一套虚假的程序。假如自己实现的话，最关键的就是协议，对于redis来说，它的通信协议相对简单，就是resp，协议格式如下：

• 单行字符串（Simple Strings）： 响应的首字节是 "+"。例如："+OK\r\n"。


• 错误（Errors）： 响应的首字节是 "-"。例如："-ERROR message\r\n"。


• 整型（Integers）： 响应的首字节是 ":"。例如：":0\r\n"。


• 多行字符串（Bulk Strings）： 响应的首字节是"$"，后面跟字符长度，然后跟字符。例如："$6\r\nfoobar\r\n"


• 数组（Arrays）： 响应的首字节是 "*"。例如："*2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n"

这就是它的通信协议，相当简单，比如我们想实现一个简单的get key操作，那么协议对应的字符格式为

*2\r\n$3\r\nget\r\n$3\r\nkey\r\n

然后传送给服务端就行。

Redis蜜罐

对于蜜罐，我们只需要实现服务端即可，客户端就用redis-cli这个工具就行。废话不多说，直接贴一下项目github.com/SSRemex/sil…

很简单，server.py实现了一个socket服务，同时加了日志收集功能。

而resp.py则实现了命令解析、命令执行、结果格式处理等操作

命令解析和结果格式主要是协议的解析和封装，这里主要想说一下两点，就是实现了一部分redis的命令

...

class RespHandler:

    def __init__(self):

        # 用来临时存储数据的字典

        self.k_v_dict = {

            "admin": "12345"

        }



        self.executable_command = {

            "ping": (self.ping, True),

            "get": (self.get, True),

            "set": (self.set, True),

            "keys": (self.keys, True),

            "auth": (self.auth, True),

            "del": (self.delete, True),

            "exists": (self.exists, True),

            "dbsize": (self.dbsize, True),

            "config": (self.config, True)



        }

        self.unexecutable_command = [

            "hget", "hset", "hdel", "hlen", "hexists", "hkeys", "hvals", "hgetall", "hincrby", "hincrbyfloat",

            "hstrlen", "shutdown", "expire", "expireat", "pexpire", "pexpireat", "ttl", "type", "rename", "renamenx",

            "randomkey", "move", "dump", "restore", "migrate", "scan", "select", "flushdb", "flushall", "mset", "mget",

            "incr", "decr", "append", "strlen", "getset", "setrange", "getrange", "rpush", "lpush", "linsert", "lrange",

            "lindex", "llen", "rpop", "lpop", "lrem", "lset", "blpop",



        ]

...

这里我内定了一些命令，并实现了他们的功能，让它像真的redis一样，你甚至可以进行kv操作，同时为了真实性，设定了一堆不可执行的命令，调用时会返回redis的报错，就像在配置文件里面禁用了这些命令一样。

演示

服务端执行，默认运行在3998端口

redis-cli连接

可以发现成功连接

此时服务端这边也接收到了，并且生成了日志

接下来，我们在redis-cli执行一些命令

很完美，甚至可以进行set get操作。

最后再次附上项目地址：github.com/SSRemex/sil…

事情是这样的 👇

前段时间我用arco.design这个组件库默认的模板项目开放，刚开始需求是这样的：总共八个页面，其中四个显示在导航栏，四个不在导航栏显示，可以导航的页面里又有俩个需要登录才能访问，俩个不登录就能访问。听着是有些绕不过开发起来不是SO EASY吗😎

我用的是vue版本的，说白了就一个知识点——路由和菜单。凭借我的聪明才智，肯定一看就会。

路由

首先，需要先了解一下路由表的配置。基本的路由配置请参阅 Vue-Router 官方文档

// 在本例子中，页面最终路径为 /dashboard/workplace

export default {

 path: 'dashboard',

 name: 'dashboard', // 路由名称

 component: () => import('@/views/dashboard/index.vue'),

 meta: {

   locale: 'menu.dashboard',

   requiresAuth: true,

   icon: 'icon-dashboard',

 },

 children: [

   {

     path: 'workplace',

     name: 'workplace',

     component: () => import('@/views/dashboard/workplace/index.vue'),

     meta: {

       locale: 'menu.dashboard.workplace',

       requiresAuth: true,

       roles: ['admin'],

       hideInMenu: false,

     },

   },

 ],

};

路由 Meta 元信息

hideInMenu 控制菜单显示， requiresAuth 控制是否需要登录，没错，以上知识点完全够我用了🤏🤏🤏🤏

三下五除二就开发完成了，正当我沉浸在成功的喜悦时，测试给我提了个bug。

说导航栏目切换，选中状态有俩个正常，俩个不正常，切换页面导航没选中，再点一次才会选中。我擦👏👏👏👏👏，我傻眼了😧😧😧

到底哪里出了问题，我哪里写错了呢，人家官方肯定没问题，于是我开始寻找。是路由名称重复了，还是那个组件写的有问题，还好有俩个正常的，我仔细比对一下不就好了吗，我可真是个小机灵鬼。

就这样，我又一次为我的自大付出了汗水，对比了一天，我感觉好像真不是我写的有问题，不过还是有收获的，我发现requiresAuth 设置为true的导航正常，requiresAuth设置为false的不正常。抱着怀疑的态度我开始找原来模板项目中处理requiresAuth的代码。最后在components》menu》index.vue文件下发现一个方法：

listenerRouteChange((newRoute) => {

   const { requiresAuth, activeMenu, hideInMenu } = newRoute.meta;

   if (requiresAuth && (!hideInMenu || activeMenu)) { 

     const menuOpenKeys = findMenuOpenKeys(

       (activeMenu || newRoute.name) as string

     );



     const keySet = new Set([...menuOpenKeys, ...openKeys.value]);

     openKeys.value = [...keySet];



     selectedKey.value = [

       activeMenu || menuOpenKeys[menuOpenKeys.length - 1],

     ];

   }

 }, true);

这... ... 我人麻了，这不是只有requiresAuth 为true的时候才会有效吗？他为啥这么写呢？还是我复制项目的时候复制错了？然后我改成了

listenerRouteChange((newRoute) => {

   const { requiresAuth, activeMenu, hideInMenu } = newRoute.meta;

   if ((requiresAuth === true || requiresAuth === false) && (!hideInMenu || activeMenu)) { 

     const menuOpenKeys = findMenuOpenKeys(

       (activeMenu || newRoute.name) as string

     );



     const keySet = new Set([...menuOpenKeys, ...openKeys.value]);

     openKeys.value = [...keySet];



     selectedKey.value = [

       activeMenu || menuOpenKeys[menuOpenKeys.length - 1],

     ];

   }

 }, true);

🙈🙈🙈🙈🙈看出来我改哪里了吗，考考你们的眼力，我改的方法是不是很nice。
反正好使了，下班！！！！

从原理上面讲，我们大众的认知就是TextureView比SurfaceView的性能要好。硬的比软的好。但是其实这种是片面的。最近就遇到一个奇怪的现象：在3399上面通过ffmpeg拉rtsp流，然后通过mediacodec解码后渲染。渲染到TextureView上会比较频繁的出现马赛克的现象。但是换用SurfaceView立马就变好了。

TextureView 和 SurfaceView 都有各自的优势和局限性，所以它们的性能表现也会因应用的具体需求和使用场景而异。
在某些情况下，TextureView 的性能可能会比 SurfaceView 差，原因可能有以下几点：

需要注意的是，性能差异可能会因设备和应用而异，因此在实际开发中应该根据具体需求和性能测试结果来选择合适的视图。无论选择哪种视图，都应该优化代码以提高性能，并确保在不同设备上进行充分的测试。

于是，我针对上面的3点的结论做了一个实验，在3399上面ffmpeg硬解码居然比软解码帧率要低。看来3399的CPU性能比其他硬件确实要抢。这就证明了标题中的疑惑了。

下面贴出一段出马赛克的代码，换上SurfaceView就好了。

public class IPCameraPreviewFragment extends Fragment implements TextureView.SurfaceTextureListener{



    public static final String TAG = "IPCameraPreviewFragment";

	public static final boolean DEBUG = true;

	

	private TextureView mPreview;

	private SurfaceTexture mSurfaceTexture;

	private Handler mUiHandler = new Handler();

	private Runnable mRunnable = new Runnable() {

        

        @Override

        public void run() {

            if(mPreview == null || mSurfaceTexture == null) return;

            Play.getInstances().startPreivew(new Surface(mSurfaceTexture));

        }

    };

    private IErrorCallback mErrorCallback = new IErrorCallback() {

        

        @Override

        public void onError(int error) {

            Log.d(TAG, "onError = " + error);

            if(null == mUiHandler || null == mRunnable) return;

            mUiHandler.removeCallbacks(mRunnable);

            mUiHandler.postDelayed(mRunnable, 5000);

        }

    };

	

	public void setDataSource(String source){

	    Play.getInstances().setErrorCallback(mErrorCallback);

		Play.getInstances().setDataSource(source);

	}

	

	@Override

	public View onCreateView(LayoutInflater inflater, ViewGr0up container, Bundle savedInstanceState) {

		View view = inflater.inflate(R.layout.preview_fragment, container,false);

		mPreview =  (TextureView)view.findViewById(R.id.preview);

		mPreview.setSurfaceTextureListener(this);

		return view;

	}

	

    @Override

    public void onSurfaceTextureAvailable(SurfaceTexture surface, int width,

            int height) {

        mSurfaceTexture = surface;

        Play.getInstances().startPreivew(new Surface(surface));

    }



    @Override

    public void onSurfaceTextureSizeChanged(SurfaceTexture surface, int width,

            int height) {

        

    }



    @Override

    public boolean onSurfaceTextureDestroyed(SurfaceTexture surface) {

        mSurfaceTexture = null;

        Play.getInstances().releaseMediaPlay();

        if(null == mUiHandler || null == mRunnable) return false;

        mUiHandler.removeCallbacks(mRunnable);

        mUiHandler = null;

        mRunnable = null;

        return false;

    }



    @Override

    public void onSurfaceTextureUpdated(SurfaceTexture surface) {

        

    }



}

大家好，这里是大家的林语冰。

本周之后，Vue 2 将停止开源维护。所以本期《前端翻译计划》共享的是某企业去年从 Vue 2 迁移到 Svelte 的现实测评，以及 Vue 3 和 Svelte 的“零和博弈”。

在使用 Vue 2 作为我们的前端框架近 2 年后，我们宣布此支持将不再维护，因此我们决定迁移到新框架。但该选谁呢：Vue 3 还是 Svelte 呢？

粉丝请注意，我们迁移后的目标也是改善 DX（开发体验），尤其是类型检查、性能和构建时间。我们没有考虑 React，因为它需要投资一大坨时间成本来学习，而且与 Vue 和 Svelte 不同，它没有提供开箱即用的解决方案。此外，后者共享相同的 SFC（单文件组件）概念：同一文件中的逻辑（JS）、结构（HTML）和样式（CSS）。

Svelte vs Vue 3

Svelte 的留存率更高。对于我们的新前端，我们必须从市场上可用的 2 个框架权衡，即 Svelte 和 Vue 3。下面是过去 5 年不同框架留存率的图示（留存率 = 会再次使用/(会再次使用 + 不会再次使用)）。JS 现状调查汇编了该领域开发者的数据，如你所见，Svelte 排名第二，而 Vue 3 排名第四。

这启示我们，过去使用过 Svelte 的开发者愿意再次使用它的数量比不愿使用它的要多。

Svelte 的类型体验更棒。

Svelte 通过更简单的组件设计流程和内置类型事件提供了更好的类型体验，对我们而言十分用户友好。

全局变量访问限制。使用 Svelte，可以从其他文件导入枚举，并在模板中使用它们，而 Vue 3 则达咩。

语法。就我个人而言，私以为 Svelte 语法比 Vue 更优雅和用户友好。您可以瞄一下下面的代码块，并亲自查看它们。

Svelte：

Vue：

没有额外的 HTML div <template>。在 Svelte 中您可以直接编写自己的 HTML。

样式在 Svelte 中会自动确定作用域，这对于可维护性而言是一个优点，且有助于避免 CSS 副作用。每个组件的样式独立，能且仅能影响该组件，而不影响其父/子组件。

更新数据无需计算属性。在 Svelte 中，感觉更像在用纯 JS 撸码。您只需要专注于编写一个箭头函数：

const reset = () => {

  firstName = ''

  lastName = ''

}

Svelte 中只需单个括号:

//Svelte

{fullName}



//Vue

{{fullName}}

添加纯 JS 插件更简单。此乃使用 Svelte 和 Prism.js 的语法高亮集成用例，如下所示：

无需虚拟 DOM 即可编译代码。Svelte 和 Vue 之间的主要区别是，减少了浏览器和 App 之间的层数，实现更优化、更快的任务成果。

自动更新。诉诸声明变量的辅助，Svelte 可以自动更新您的数据。这样，您就不必等待变更反映在虚拟结构中，获得更棒的 UX（用户体验）。

Svelte 也有短板

理所当然，Svelte 也有短板，比如社区相对较小，因为它是 2019 年才诞生的。但随着越来越多的开发者可能会认识到其质量和用户友好的内容，支持以及社区未来可能会不断发展壮大。

因此，在审查了此分析的结果后，尽管 SvelteKit 在迁移时仍处于积极开发阶段，我们决定使用 Svelte 和 Svelte Kit 砥砺前行。

如何处理迁移呢？

时间：我们选择在 8 月份处理迁移，当时该 App 用户较少。

时间长度：我们花了 2 周时间将所有文件从 Vue 迁移到 Svelte。

开发者数量：2 名前端开发者全职打工 2 周，另一名开发者全职打工 1 周，因此涉及 3 名开发人员。

工作流：首先，我们使用 Notion 工具将我们的凭据归属于团队的开发者。然后，我们开始在 Storybook 中创建新组件，最后，每个开发者都会奖励若干需要在 Svelte 中重写的页面。

作为一家初创公司，迁移更简单，因为我们没有 1_000 个文件需要重写，因此我们可以快速执行。虽然但是，当 SvelteKit 仍处于积极开发阶段时，我们就冒着风险开始迁移到 SvelteKit，这导致我们在迁移仅 1 个月后就不得不做出破坏性更新。但 SvelteKit 专业且博大精深的团队为我们提供了一个命令（npx svelte-migrate routes），以及一个解释清晰的迁移指南，真正帮助我们快速适应新的更新。

此外，9 月份，SvelteKit 团队宣布该框架终于进入候选版本阶段，这意味着，它的稳定性现在得到了保证！

文件和组件组织：

SvelteKit 的“文件夹筑基路由”给我们带来了很多。我们可以将页面拆分为子页面，复用标准变量名，比如 loading/submit 等等。此外，布局直接集成到相关路由中，由于树内组织的增加，访问起来更简单。

那么我们得到了什么？

除了上述好处之外，还值得探讨其他某些关键因素：

性能提高且更流畅。编译完成后，我们可以体会到该 App 的轻量级。与其他框架相比，这提高了加载速度，其他框架在 App 的逻辑代码旁嵌入了“运行时”。

DX 更棒。SvelteKit 使用 Vite 打包器，此乃新一代 JS 构建工具，它利用浏览器中 ES 模块的可用性和编译为原生（compile-to-native）的打包器，为您带来最新 JS 技术的最佳 DX。

代码执行更快。它没有虚拟 DOM，因此在页面上变更时，需要执行的层数少了一层。

启动并运行 SSR（服务器端渲染）。如果最终用户没有良好的互联网连接或启用 JS，平台仍将在 SSR 的帮助下高效运行，因为用户仍能加载网页，同时失去交互性。

代码简洁易懂。Svelte 通过将逻辑（JS）、结构（HTML）和样式（CSS）分组到同一文件中，可以使用更具可读性和可维护性的面向组件的代码。黑科技在于所有这些元素都编译在 .svelte 文件中。

固定类型检查。自从我们迁移到 Svelte 以来，我们已经成功解决了类型检查的最初问题。事实上，我们以前必须处理周期性的通知，而如今时过境迁。不再出现头大的哨兵错误。（见下文）

粉丝请注意，此博客乃之前的迁移测评，其中某些基准测试见仁见智，尤大还亲自码字撰写博客布道分享，我们之后会继续翻译 Vue 官方博客详细说明。

免责声明

本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考，英文原味版请传送 Migrating from Vue 2 to Svelte。

您现在收看的是《前端翻译计划》，学废了的小伙伴可以订阅此专栏合集，我们每天佛系投稿，欢迎关注地球猫猫教。谢谢大家的点赞，掰掰~

前言

相信各位程序猿/程序媛小朋友都有想创业赚外快的梦想，梦想哪一天自己能做出来个爆款产品，用户量蹭蹭的涨，真金白银哗哗的涌进来，挡都挡不住，从此当上总经理、出任CEO、赢取白富美、走上人生巅峰。或者退而求其次，产品虽然不那么火。但也可以让自己每天躺着也能挣钱，副业的收入就足够日常开销，那个班随便上上就行了，还卷什么卷。

而做副业的各种途径中，做微信小程序无疑是门槛比较低的途径之一，微信国内几乎每个人都在用，那数量庞大的用户和流量无人能及，小程序天然跨平台，运行体验也比原生h5似乎流畅那么一点点。

最关键的是开发成本低啊，只要有一点点JS基础，分分钟就能搞出来个能跑的小程序，不会后端也没关系，有云开发，照着文档，基本的增删改查也是分分钟就能搞定。

注册一个账户很简单，做完的小程序上架也很简单。一切都很简单有木有。看到这里你是不是想立马手搓个小程序试试？

然而，时代已经变了，看似简单的小程序做起来已经不那么简单了。现在我已经不建议大家在做副业的时候选择微信小程序了。

回顾

在说明为什么不建议再做小程序之前，先来回顾一下个人做小程序之前为什么是可行的。

创业也好，做副业也好，首先得看大趋势，雷总不是有句名言嘛，“站在风口上，猪都能飞起来”，换句话说，赚钱要趁早，智能手机刚起步的时候去做app，微信刚推出小程序的时候你去做小程序，那赚钱的可能性都比较大，毕竟是蓝海，而现在，app，小程序啥的早就是一片红海了。有多么红海，你随便搜一下“小程序已死”就知道了，基本上有需求的地方都已经有小程序占好坑了。对个人做小程序来讲那时也是最好的时候，做成的概率也比较大。

当然，错过了风口也不是完全没机会，虽然小程序变红海已经好长时间了，但是架不住万一你突然发现了哪个小众需求，或者蹭到了哪个热点，比如前一段火的不行的短视频去水印，虽然靠这个没法财富自由，但赚个零花钱还是可以的。

做任何事情都是开始最困难，不是有句老话叫“万事开头难”么。而小程序曾经就可以把这个开头的难度降低很多，除了上面讲的开发难度低，另一个就是试错的成本也低。如果一个小程序做不起来可以迅速再搞一个其他小程序试试，甚至可以弄出来一堆小程序，哪个能活下来就重点运营，其他不行的可以放弃后再搞新的，基本上除了开发没有其他的成本。

最重要的一个点就是，虽然平台对个人主体仅开放了有限的类目，理论上讲，个人能做的小程序基本上被限制在工具类里面，比如都被做烂了的记账，备忘录啥的。我们都知道小程序的分享能力是非常重要的，可以分享才能裂变出新用户，新流量。

虽然原则上你的小程序是不能把用户创作的内容分享出去的，一旦涉及到分享，就被归为社交类目，而这个类目是不对个人开放的，举个例子，你搞了个制作头像的小程序，那用户制作好的头像是不能发给别人的，只能保存在本地。

但是呢，之前微信小程序平台对这些个规则执行的并不是十分严格。这就存在一些可操作的空间，让你上线一些只有公司才可以做的小程序。

所以，这里就有了一个可以低成本试错的路径，你可以先利用这个模糊空间，拍脑门也好，蹭热点也罢，先以个人名义上线小程序，如果不理想，就直接弃用或者换名字改成其他类型的小程序再试，扔掉的成本基本上就只是开发成本。如果不小心成了爆款，那恭喜你，可以去成立个公司啥的，再把小程序迁移过来，然后成为CEO，赢取白富美，走上人生巅峰。。。

不幸的是，现在，这条路已经被堵死了。

变化

为啥说路被堵死了，因为最近发生了一些变化，让个人开发者的试错成本直线上升，甚至可以说根本无路可走了。

创业或者搞副业无非就是要赚钱，收入减去成本就是赚到的钱。那就从成本，收入两个角度来分析一下发生了什么导致现在搞小程序很难赚到钱。

成本

先看成本，成本飙升到能把个人开发者的路都堵死，还得从微信这一年的一系列操作说起。这波操作总结起来就是一个字：“得加钱”

云开发，个人开发者用来快速整个后端，一年多前起步免费，现在起步价：优惠19.9/月，原价：39.9/月，起步价里面包含的资源也就够你开发调试用吧，上线以后超出部分另算。

个人小程序的自然流量基本上都依靠搜索，在We分析里可以看到用户通过搜索哪些关键词访问到小程序，开发者可以相应的做搜索词优化来引流。自12月18日起，这项功能也开始收费了，起步价388/年，这个起步价啥概念？你的小程序过去一段时间日打开次数得小于100次。。。

以上都是平a，下面这个才是大招，“必杀技：备案+认证无敌真伤斩杀组合拳”

先说认证，认证这事之前仅对企业等非个人主体开放的，300一个小程序，不管认证能不能通过，如果通过了就是永久有效。个人小程序无需认证。

然而，从下半年开始，个人小程序也需要认证了，目前优惠价30每个小程序，而且认证有效期只有一年了。不认证也可以，那你的小程序就别想被搜索到，也别想往外分享了。

你说你去认证吧，就会遇到另外一个问题，认证的时候要审核你的小程序的名字。做过小程序的都知道，名字可太重要了。直接决定了你的小程序能不能被搜索到。所以之前大家起名几乎都是在直接对标搜索热门词，什么“群签到助手”，什么“去水印神器”之类的。

然而现在在认证的时候这些名字统统不合格，名字不能太宽泛，必须含有个人特征。例如，张三做了个“记事本”小程序去认证，那名字几乎得叫“张三的记事本”之类才好通过。想蹭流量？门都没有。

再说下一个，备案。从9月4号开始，所有新小程序必须备案后才能上线，已上线的小程序在明年4月之前必须完成备案，否则就下架。

平台会对要备案的小程序做初审，这个初审就相当严格了。把个人小程序直接按死在那有限的几个类目里。基本上现在个人只能做记事本三件套了。前面说的模糊空间已经不存在了，路也就堵死了。

你要说能不能先通过备案，然后在新版本里添上新功能？不好意思，现在对版本的审核也很严格。以前几个小时就能审好，现在几天都是正常的，有超过资质范围的功能直接打回。

备案也会对小程序名字做审核，你要问啥样的名字能过审？别问我，我也不知道。

由于认证和备案不是同一拨人在搞，所以如果你的小程序不太幸运的话会遇到以下问题：

30认证 --> 认证不通过 --> 改名+30认证 --> 认证通过 --> 备案不通过 --> 改名+30认证。。。

就说为了个小程序，你能不能经得住这样的折腾吧。

至于看不懂的文档，日常的违规警告，无法找到的人工客服，随便废弃接口，隐私协议闹剧（具体可看《各位微信小程序的开发者们，你们还好吗？》）等等大家都早已经麻了。

成本讲完了，下面说说收入。

收入

什么？你还想着有收入？收入就是没有收入！（全文完）

------------------------- 分 ----- 割 ----- 线 ------------------------

说没有收入，是玩笑话，也不是玩笑话。小程序除非你另有门路，大部分个人开发者就只能靠当流量主接入平台的广告赚钱。然而，现在广告的ecpm虽然不能说聊胜于无，也可以说是惨不忍睹。并且这下降的趋势似乎还看不到头，简直和股市一个尿性。

就那点广告费收入，再减去上面说的成本，能不亏钱就不错了，至于收益，这么说吧，
去各大平台薅羊毛，每天在某东签个到，在某宝果园里种个树，农场里养个鸡，或者在某音某手放一个你好基友啪叽在冰面上摔个狗啃泥的短视频，获得的收益都可能比苦哈哈做小程序的收益多。

某多多除外，你永远都别想薅到某多多的羊毛。

总结

个人做小程序的成本和收益都写在上面了，干货满满。各位想着做副业的小朋友看完之后不妨自己先算算账，然后再决定要不要做小程序。另外大家对此还有什么想吐槽的，欢迎在讨论区一起聊聊。

关于降本增效的事，今天在网上看到一个帖子，虽然有点搞笑，但是对于打工人（特别是技术同学）来说，可挖掘的东西也不少，特别分享给大家。

真的是好多年没听说这样的事了，记得以前总有老板让做个淘宝、做个京东，然后预算只有几千块，最多几万块。

这些故事程序员谈起来往往都是哈哈一笑，并疯狂吐槽一番。

不过笑过之后，大家是否想过如何去解决问题？或者真的去评估下可行性，探索一下可能的实现路径。

找到问题

首先我们看下老板的问题。老板的根本问题并不是想要做金蝶，为什么这么说呢？

我们看看网友的描述就知道了：经济下行，领导不想出金蝶系统的维护费，不想为新功能花大价钱。这才是根本问题，用四个字来说就是：降低成本。

然后才是老板想到能不能用更少的钱达到金蝶系统的使用效果，再之后才是自己能不能做一个类似金蝶的系统，并思考了自己可以承担的成本：一个前端、一个后端，半年时间。

最后问题被抛到了这位网友的手里。可以看得出来这位网友也不太懂，还去咨询了朋友。不知道它有没有向朋友说清楚问题，还是只说了老板想自己做一个金蝶系统，结果是朋友们都说不可行。

遇到问题时，我们得把这个问题完完整整的捋一遍，找到最根本的问题，然后再说怎么解决问题，否则只是停留在表面，就可能事倍功半。在这个上下文中，根本的问题就是：降低成本。

解决问题

明确了老板的根本问题，我们就可以琢磨方案了。既然是降低财务系统的成本，可行的方案应该还是有几个的。

使用替代产品

假如公司只使用产品的部分功能，是不是可以选择金蝶的低版本？是不是可以降低一些人头费？

金蝶的服务贵，是不是可以选择一些小厂的产品？国内做财务系统的应该挺多的，小厂也更容易妥协。

或者选择SaaS服务，虽然SaaS用久了成本也不低，但是可以先撑过这几年，降低当前的支出。

当然替换财务系统也是有成本的，需要仔细评估。不过既然都想自己做了，这个成本应该能hold住。

找第三方维护

金蝶的服务贵，是不是可以找其它三方或者个人来维护修改？根据我之前的了解，金蝶这种公司有很多的实施工作是外包出去的，或者通过代理商来为客户服务，能不能找这些服务商来代替金蝶呢？或者去某些副业平台上应该也能找到熟悉金蝶系统的人。

当然这个还要看系统能不能顺利交接，金蝶有没有什么软硬件限制，第三方能不能接过来。

另外最重要的必须考虑系统和数据的安全性，不能因小失大。

自己开发

虽然自己开发的困难和成本都很高，但我仍旧认为这可能也是一个合适的解决方案。理由有下面两点。

• 功能简单：如果公司的业务比较简单，使用的流程也简单，比如不使用涉及复杂的财务处理，那么捋一捋，能给开发人员讲清楚，也是有可能在短时间内完成的。


• 迭代渐进：长城不是一天建成的，系统也都是逐渐迭代完善的。自己开发可以先从部分模块或者功能开始，然后逐步替换，比如前边的流程先在新系统中做，最后再导入金蝶。即使不能做到逐步替换，也可以控制系统的风险，发现搞不定时，及时止损。相信老板也能明白这个道理，如果不明白或者不接受，那确实搞不了。

当然我们也肯定不能忽视这其中的困难。我之前做过和金蝶系统的对接，订单的收付款在业务系统完成，然后业务系统生成凭证导入到金蝶K3。依稀记得业务也不算复杂，但是需求分析做了好几遍，我的代码也是改了又改，上线之后遇到各种问题，继续改，最终花了几个月才稳定下来。

事后分析原因，大概有这么几点：

• 产品或者需求分析人员没接触过类似的业务，即使他对财务系统有一些经验，也不能准确的将客户的业务处理方式转换到产品设计中；


• 财务人员说不明白，虽然他会使用金蝶系统，但是他不能一次性的把所有规则都讲出来，讲出来也很难让程序员在短时间内理解；


• 程序员没做过财务系统，没接触过类似的业务，系统的设计可能要反复调整，比如业务模块的划分逻辑，金额用Long还是用BigDecimal，数据保留几位小数，这都会大幅延长开发周期，如果不及时调整就可能写成一锅粥，后期维护更困难。

这还只是和金蝶系统做一个简单的对接，如果要替代它，还要实现更多的功能，总结下，企业可能会面对下面这些困难：

业务复杂：财务规则一般都比较复杂，涉及到各种运算，各种数字、报表能把人搞晕。如果公司的业务也很复杂，比如有很多分支或者特殊情况，软件开发的难度也会很大，这种难度的变化不是线性增加的，很可能是指数级增长的，一个工作流的设计可能就把人搞死了。

懂业务的人：系统过于复杂时，可能没有一个人能把系统前前后后、左左右右的整明白。而要完成这样一个复杂的系统，必须有人能从高层次的抽象，到具体数字运算的细枝末节，完完全全的整理出来，逻辑自洽，不重不漏，并形成文档，还要能把程序员讲明白。

懂架构的人：这里说的是要有一个经验丰富的程序员，不能是普通的码农，最好是有财务系统开发经验的架构师。没走过的路，总是要踩坑的。有经验的开发人员可以少走很多弯路，极大降低系统的风险。这样的人才如果公司没有，外招的难度比较大，即使能找到，成本也不低。

灵活性问题：开发固定业务流程的系统一般不会太考虑灵活性的问题，如果业务需要调整，可能需要对系统进行大幅修改，甚至推倒重来。如果要让系统灵活些，必然对业务和技术人员都提出了更高的要求，也代表着更强的工作能力和更多的工作量。

和其它系统的对接：要不要和税务系统对接？要不要和客户管理系统对接？要不要和公司的OA对接？每一次对接都要反复调试，工作量肯定下不来。

总之，稍微涉及到财务处理的系统，都不是一个前端和一个后端能在短时间内完全搞出来的。

对程序开发的启示

搞清楚需求

日常开发过程中，大家应该都遇到过不少此类问题。领导说这里要加个功能，然后产品和开发就去吭哧吭哧做了，做完了给领导一看，不是想要的，然后返工反复修改。或者说用户提了一个需求，产品感觉自己懂了，然后就让开发这么做那样改，最后给用户一看，什么破玩意。这都是没有搞清楚真正的需求，没有触达那个根本问题。

虽然开发人员可以把这些问题全部甩给产品，自己只管实现，但这毕竟实实在在的消耗了程序员的时间，大量的时间成本和机会成本，去干点有意义的事情不好吗？所以为了不浪费时间，开发也要完整的了解用户需求。在一个团队中，至少影响产品落地的关键开发人员要搞懂用户的需求。

那么遇到这种问题，程序员是不是可以直接跑路呢？

也是一个选择， 不过对于一个有追求的程序员，肯定也是想把程序设计好、架构好的，能解决实际问题的，这也需要对用户需求的良好把控能力，比如我们要识别出哪些是系统的核心模块，哪些是可扩展能力，就像设计冯诺依曼计算机，你设计的时候会怎么处理CPU和输入输出设备之间的关系呢？

对于用户需求，产品想的是怎么从流程设计上去解决，开发需要考虑的是怎么从技术实现上去满足，两者相向而行，才能把系统做好。

当然准确把握用户的需求，很多时候并不是我说的这么容易，因为用户可能也说不清楚，我们可能需要不断的追问才能得到一些关键信息。比如这位网友去咨询朋友时，可能需求就变成了：我们要做一个财务系统，朋友如果不多问，也只能拿到这个需求，说不定这位朋友也有二次开发的能力，错失了一次挣钱的好机会。还有这位老板上边可能还有更大的老板，这位老板降低成本的需求也可能是想在大老板面前表现一下，那是不是还有其它降本增效的方法呢？比如简化流程、裁掉几个不关键的岗位（这个要得罪人了）。

我们要让程序始终保持在良好的状态，就要准确的把握用户需求，要搞懂用户需求，就需要保持谦逊求知的心态，充分理解用户的问题，这种能力不是朝夕之间就可以掌握的，是需要修炼的。

动起来

任何没有被满足的需求都是一次机会。

我经常会在技术社区看到一些同学分享自己业余时间做的独立产品，有做进销存的、客户管理的、在线客服的，还有解决问题的各种小工具，而且有的同学还挣到了钱。

我并不是想说让大家都去搞钱，而是说要善于发现问题、找到机会，然后动起来、去实践，实践的过程中我们可以发现更多的问题，然后持续解决问题，必然能让自己变得越来越强。在经济不太好的情况下，我们才有更强的生存能力。

啰里八嗦一大堆，希望能对你有所启发。

关注萤火架构，加速技术提升。

众所周知，编程语言的种类实在是太多了。直到现在，经常还会看到关于编程语言选择和学习的讨论。

虽说编程语言有好几百种，但实际项目使用和就业要求的主流编程语言却没有那么多。

大家可能也会好奇：现如今就业市场上到底什么编程语言最受欢迎？或者说最需要的编程语言是什么？

所以今天我们就结合Devjobsscanner之前发布的「Top 8 Most Demanded Programming Languages in 2023」编程语言清单来聊一聊这个问题。

虽说这个清单并不是完全针对我们本土开发者的调查，但还是能反映一些趋势的，大家顺带也可以参看一下各种编程语言的发展趋势和前景。

Devjobsscanner是一个综合性开发者求职/岗位信息聚合网站。

上面聚合展示了很多开发者求职岗位信息，并按多种维度进行分类，以便用户进行搜索。

该网站每年都会发布一些相关方面的调查总结报告，以反映开发者求职方面的趋势。

从2022年1月到2023年5月，这17个月的时间里，Devjobsscanner分析了超过1400万个开发岗位，并从中进行筛选和汇编，并总结出了一份「2023年需求量最大的8种编程语言」榜单。

所以下面我们就来一起看一看。

No.1 JavaScript/TypeScript

基本和大家所预想到的一样，Javascript今年继续蝉联，成为目前需求最大的编程语言。

当然这也不难理解，因为基本上有Web、有前端、有浏览器、有客户端的地方都有JavaScript的身影。

而且近几年TypeScript的流行程度和需求量都在大增，很多新的前端框架或者Web框架都是基于TypeScript编写的。

所以学习JavaScript/TypeScript作为自己的主语言是完全没有问题的。

• 职位数量/占比变化趋势图

No.2 Python

榜单上排名第二的是Python编程语言。

众所周知，Python的应用范围非常广泛。

从后端开发到网络爬虫，从自动化运维到数据分析，另外最近这些年人工智能领域也持续爆火，而这恰恰也正是Python活跃和擅长的领域。

尤其最近几年，Python强势上扬，这主要和这几年的数据分析和挖掘、人工智能、机器学习等领域的繁荣有着不小的关系。

• 职位数量/占比变化趋势图

No.3 Java

榜单中位于第三需求量的编程语言则是Java。

自1995年5月Java编程语言诞生以来，Java语言的流行程度和使用频率就一直居高不下，并且在就业市场上的“出镜率”很高。

所以每次调查结果出来，Java基本都榜上有名，而且基本长年都维持在前三。

Java可以说是构成当下互联网繁荣生态的重要功臣，无数的Web后端、互联网服务、移动端开发都是Java语言的领地。

• 职位数量/占比变化趋势图

No.4 C#

看到C#在榜单上位列前四的那会，说实话还是挺意外的，毕竟自己周围的同学和同事做C#这块相对来说还是较少的。

但是C#作为一种通用、多范式、面向对象的编程语言，在很多领域其实应用得还是非常广泛的。

我们都知道，其实像.NET和Unity等框架在不少公司里都很流行的，而C#则会被大量用于像Unity等框架的项目编写。

• 职位数量/占比变化趋势图

No.5 PHP

看到PHP在榜单上位列第五的时候，不禁令人又想起了那句梗：

不愧是最好的编程语言（手动doge）。

所以以后可不能再黑PHP了，看到没，这职位数量和占比还是非常高的。

• 职位数量/占比变化趋势图

No.6 C/C++

C语言和C++可以说都是久经考验的编程语言了。

C语言于1972年诞生于贝尔实验室，距今已经有50多年了。

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

C语言和C++的应用领域都非常广泛，在一些涉及嵌入式、物联网、操作系统、以及各种和底层打交道的场景下都有着不可或缺的存在意义。

• 职位数量/占比变化趋势图

No.7 Ruby

Ruby这门编程语言平时的出镜率虽然不像Java、Python那样高，但其实Ruby的应用领域还是挺广的，在包括Web开发、移动和桌面应用开发、自动化脚本、游戏开发等领域都有着广泛的应用。

Ruby在20世纪90年代初首发，并在2000年代初开始变得流行。

Ruby是一种动态且面向对象的编程语言，语法简单易学，使用也比较灵活，因此也吸引了一大批爱好者。

• 职位数量/占比变化趋势图

No.8 GO

虽说Go语言是一个非常年轻的编程语言（由谷歌于2009年对外发布），不过Go语言最近这几年来的流行程度还是在肉眼可见地增加，国内外不少大厂都在投入使用。

众所周知，Go语言在编译、并发、性能、效率、易用性等方面都有着不错的表现，也因此吸引了一大批学习者和使用者。

• 职位数量/占比变化趋势图

完整表单

最后我们再来全局看一看Devjobsscanner给出的编程语言完整表单和职位数量/占比的趋势图。

不难看出，JavaScript、Python和Java这三门语言在就业市场上的需求量和受欢迎程度都很大，另外像C语言、C#、Go语言的市场岗位需求也非常稳定。

总体来说，选择清单里的这些编程语言来作为自己的就业主语言进行学习和精进都是没有问题的。

说到底，编程语言没有所谓的好坏优劣，而最终选择什么，还是得看自己的学习兴趣以及使用的场景和需求。

一年一年又一年

一岁一岁又一岁

岁岁愁

  都说35是程序猿的一道坎，30的我也开始慌，开始愁了，都说应该要有个副业，可又不知道做什么，要是以后失业了，也不知道能转行做啥，好愁~有没大佬带飞  (இωஇ)没钱

失业寻找工作

  22年底公司项目砍了然后就是被离职了，当时疫情还没彻底解封，刚刚找了2个星期的工作，所在的小区就被封了。我是住在广州海珠区康乐村隔壁小区的，当时康乐村可谓闹得人人皆知，疫情的严重带，导致小区被封了1个月。之后在刚解封的时候，我又立刻中招了，发烧几天，咳嗽了也差不多一个月，期间也没怎么去找过工作，也接近过年了。

  虽然没了工作，但还是要开开心心的过个年的啦，工作什么的，年后再考虑了。

  过完年之后，疫情基本也全面放开了，不影响找工作了，就开始了每天疯狂的投投投，拉勾上看到一个符合的就投一个，保持在每天至少面一次的频率。奈何技术相对较差，又是工作了7年的老猿，面的都是小厂，但面试上还是有点不堪。面了两个星期，最终拿到两个offer，开出的条件几乎一样，都是单双休。虽然条件还是不太满意，但迫于已经几个月没工作了，每个月还有房贷在，还是有点压力的，就选择了各方面相对好一丢丢的一家，也就是目前在职的这一家。

入职搬砖

  二月底进行入职，入职之后先是熟悉环境，自己配置下电脑的开发环境，一天就过去了。第二天，就开始分配任务了，了解到我所在的项目是刚开的新项目，Android端一直没招到人开发，但服务端和iOS端已经是22年底就开始开发了的，已经领先了3个月。刚开始听到这个，感觉还是有压力的，相当于我需要赶进度去追这3个月的落差。所幸在我开始开发的时候，产品经理也跟我说了，按正常速度开发就行，不需要去加班加点赶。嗯，那还好，不然这3个月的差距，至少也得加班1-2个月才能赶上。

开始搬砖

  刚开始，还是有点懵的，产品经理说项目文档是别人出的，他也是上年底入职接手的，所以很多文档没看到，也可能是没出，就让我直接对着设计稿和iOS的做就可以了。之后我就拿了iOS的过来看，和设计稿进行了一次对比，又发现iOS和设计稿的有很多差别，iOS就跟我说他是最新的，有些细节和UI沟通过后，他没有进行修改设计稿，而是直接让iOS修改，所以让我直接照着iOS弄就可以了。emmmm....这给后面埋了个巨坑。

  由于Android这边有java和kotlin两种语言，于是问了下主管，主管让我用java去开发，也许考虑kotlin还不完善，怕项目出什么bug吧。拿着设计稿和iOS的app，就开始了疯狂敲代码模式。kotlin我是刚学了几个月，还不是太熟，但java可是用了6年多的了，那是嘎嘎香，拿着之前封装好的框架就是一顿套，什么网络请求框架、MVVM、图片加载Glide、BaseActivity等，套完之后，项目的雏形就完成了。不得不说，选择java也让我能直接使用已经封装的框架，要是kotlin，那就只能先慢慢搭建一套了，毕竟之前没怎么用过kotlin实际开发过项目，所以没什么存货。

  项目开始时，也了解到目前iOS端只是搭建了界面，服务端接口还未提供，数据模型等还没出，大概时服务端也是刚加入项目不久吧。所以iOS这期间基本都是对界面的修修补补，直到服务端出接口文档才能继续下一步，这刚好也能给我点追赶的时间。

  经过一顿嘎嘎猛敲，时间来到了4月中，期间服务端接口也出了，iOS也对接了，接口基本是没问题了，1个半月左右，我的界面也基本搭完了，就开始对接接口。刚开始还是有点难点，得按照服务端制定的规则进行加解密请求数据，编写的时候经常因为顺序和服务端的对不上导致加解密后数据是错的，调了整整2天才把加解密的调通。调通之后，其它也没啥了，正常的对接数据模型、对接接口、测试数据是否正确啥的。

搬砖完毕，进行检验

  5月初自测没问题之后进行提测了，iOS期间因为数据模型和他原本使用的模型对不上，说是改动很大，所以花了很多时间，最终和我同时提测的。

  重点来了，提测之后，测试部反馈了200+的bug数量...我当时就震惊了，我工作7年了，就没遇到能有200+bug的，这是什么神测试？结果...一看提的测试问题，一半以上是界面问题。emmmm...巨坑出来了，测试说和设计稿没对上，我说我是照着iOS做的，iOS说他是最新的，和UI对过没问题的。嗯，我以为是真的没问题，结果，UI设计师说他没说iOS那个是最新的，那些iOS虽然和他讨论过，但是他没确认可以，是iOS自己修改的。emmmmm...什么神操作，只是讨论过，没有设计师的确认，就自己修改了，还跟我说是最新的，和UI设计师确认过了的。emmmmm...能怎么办，改呗！！

  改了半个月，终于全部没问题可以上线了，真是艰难啊！！7年来，第一次遇到这种操作，真是糟心了！！期间iOS的其它问题，也不拿出来说了，评论别人不太合适。

收楼装修走起

  转眼来到6月份啦，房子终于建好收楼了，期间还是有点担心会烂尾的，毕竟恒大那么大的盘，说烂尾就烂尾，说破产就破产，要是变成烂尾楼，那简直就是天塌了，白花花的银子就全没了。

  收楼后就要开始搞装修的事啦~原本没打算今年装修的，还想再存点钱，毕竟装修要花一大笔，但父母说什么今年双春，明年没春，所以要今年入伙，就只有火急火燎的去看看装修了。考虑单双休，没时间去看，所以就找了装修全包的公司。找了1个多月，对比了5、6家公司，最终确定了一家，也差不多到10月初了，才进行签合同。期间又要物业审核什么的，拖了一个多月，11月中才开始装修。

第二个版本

  中间基本都是优化迭代，后面第二个大版本，从8月中开始，这次终于没有坑了，可以对着设计稿、交互文档来正常开发了。一开始主管要我们给个版本开发时间，因为内容有点多，加上有几个界面需要进行自定义的，我就预计了接近2个月。iOS看了就吐槽我说这么快，哪里弄的完，界面那么复杂...我也没法说啥，毕竟我预估的，已经很充足的了，再长就真的有点说不过去了。后面开发下来，也确实是差不多的，10月初就提测了，还不到两个月...然而...iOS到12月中才进行提测，这让我有点震惊。期间我都迭代了1个版本了，只能说主管貌似对进度不太关心。

学习鸿蒙

  由于iOS进度相对慢的有点多，所以我这边也自然多出了很多时间，刚好今年华为搞事情了，鸿蒙后续版本将不会再适配Android的apk了，需要进行单独开发，我刚好可以利用这段空闲的时间学学HarmonyOS，虽然感觉可以再缓缓，不用那么快学习，毕竟刚出，问题肯定相对较多，还需要一段时间让HarmonyOS的api完善完善，bug再修改修改。因为22年中下旬离职前，花了2、3个月的时间学习过JetpactCompose，所以学习HarmonyOS的ArkUI来说，相对轻松点，基本和JC有很多一样的用法。目前ArkUI也能做个简单的APP了，但还没开始看自定义视图，后面再学学，视图方面就基本可以了，主要还是各种优化和ArkTS的Api熟悉。

总结

  没想到一晃眼就一年过去了呢，今年除了一开始找工作、收楼找装修外，也没啥大事发生了，埋头敲敲代码就年底了，希望明年会越来越好！！

大家好，我是哪吒。

在开发中，我们经常会遇到这样的需求，将Excel的数据导入数据库中。

一、一般我会这样做：

操作起来，如果文件比较多，数据量都很大的时候，会非常慢。

访问之后，感觉没什么反应，实际上已经在读取 + 入库了，只是比较慢而已。

读取一个10万行的Excel，居然用了191s，我还以为它卡死了呢！

private void readXls(String filePath, String filename) throws Exception {

    @SuppressWarnings("resource")

    XSSFWorkbook xssfWorkbook = new XSSFWorkbook(new FileInputStream(filePath));

    // 读取第一个工作表

    XSSFSheet sheet = xssfWorkbook.getSheetAt(0);

    // 总行数

    int maxRow = sheet.getLastRowNum();



    StringBuilder insertBuilder = new StringBuilder();



    insertBuilder.append("insert int0 ").append(filename).append(" ( UUID,");



    XSSFRow row = sheet.getRow(0);

    for (int i = 0; i < row.getPhysicalNumberOfCells(); i++) {

        insertBuilder.append(row.getCell(i)).append(",");

    }



    insertBuilder.deleteCharAt(insertBuilder.length() - 1);

    insertBuilder.append(" ) values ( ");



    StringBuilder stringBuilder = new StringBuilder();

    for (int i = 1; i <= maxRow; i++) {

        XSSFRow xssfRow = sheet.getRow(i);

        String id = "";

        String name = "";

        for (int j = 0; j < row.getPhysicalNumberOfCells(); j++) {

            if (j == 0) {

                id = xssfRow.getCell(j) + "";

            } else if (j == 1) {

                name = xssfRow.getCell(j) + "";

            }

        }



        boolean flag = isExisted(id, name);

        if (!flag) {

            stringBuilder.append(insertBuilder);

            stringBuilder.append('\'').append(uuid()).append('\'').append(",");

            for (int j = 0; j < row.getPhysicalNumberOfCells(); j++) {

                stringBuilder.append('\'').append(value).append('\'').append(",");

            }

            stringBuilder.deleteCharAt(stringBuilder.length() - 1);

            stringBuilder.append(" )").append("\n");

        }

    }



    List<String> collect = Arrays.stream(stringBuilder.toString().split("\n")).collect(Collectors.toList());

    int sum = JdbcUtil.executeDML(collect);

}



private static boolean isExisted(String id, String name) {

    String sql = "select count(1) as num from " + static_TABLE + " where ID = '" + id + "' and NAME = '" + name + "'";

    String num = JdbcUtil.executeSelect(sql, "num");

    return Integer.valueOf(num) > 0;

}



private static String uuid() {

    return UUID.randomUUID().toString().replace("-", "");

}

二、谁写的？拖出去，斩了！

优化1：先查询全部数据，缓存到map中，插入前再进行判断，速度快了很多。

优化2：如果单个Excel文件过大，可以采用 异步 + 多线程 读取若干行，分批入库。

优化3：如果文件数量过多，可以采一个Excel一个异步，形成完美的双异步读取插入。

使用双异步后，从 191s 优化到 2s，你敢信？

下面贴出异步读取Excel文件、并分批读取大Excel文件的关键代码。

1、readExcelCacheAsync控制类

@RequestMapping(value = "/readExcelCacheAsync", method = RequestMethod.POST)

@ResponseBody

public String readExcelCacheAsync() {

    String path = "G:\\测试\\data\\";

    try {

		// 在读取Excel之前，缓存所有数据

        USER_INFO_SET = getUserInfo();



        File file = new File(path);

        String[] xlsxArr = file.list();

        for (int i = 0; i < xlsxArr.length; i++) {

            File fileTemp = new File(path + "\\" + xlsxArr[i]);

            String filename = fileTemp.getName().replace(".xlsx", "");

            readExcelCacheAsyncService.readXls(path + filename + ".xlsx", filename);

        }

    } catch (Exception e) {

        logger.error("|#ReadDBCsv|#异常: ", e);

        return "error";

    }

    return "success";

}

2、分批读取超大Excel文件

@Async("async-executor")

public void readXls(String filePath, String filename) throws Exception {

    @SuppressWarnings("resource")

    XSSFWorkbook xssfWorkbook = new XSSFWorkbook(new FileInputStream(filePath));

    // 读取第一个工作表

    XSSFSheet sheet = xssfWorkbook.getSheetAt(0);

    // 总行数

    int maxRow = sheet.getLastRowNum();

    logger.info(filename + ".xlsx，一共" + maxRow + "行数据！");

    StringBuilder insertBuilder = new StringBuilder();



    insertBuilder.append("insert int0 ").append(filename).append(" ( UUID,");



    XSSFRow row = sheet.getRow(0);

    for (int i = 0; i < row.getPhysicalNumberOfCells(); i++) {

        insertBuilder.append(row.getCell(i)).append(",");

    }



    insertBuilder.deleteCharAt(insertBuilder.length() - 1);

    insertBuilder.append(" ) values ( ");



    int times = maxRow / STEP + 1;

    //logger.info("将" + maxRow + "行数据分" + times + "次插入数据库！");

    for (int time = 0; time < times; time++) {

        int start = STEP * time + 1;

        int end = STEP * time + STEP;



        if (time == times - 1) {

            end = maxRow;

        }



        if(end + 1 - start > 0){

            //logger.info("第" + (time + 1) + "次插入数据库！" + "准备插入" + (end + 1 - start) + "条数据！");

            //readExcelDataAsyncService.readXlsCacheAsync(sheet, row, start, end, insertBuilder);

            readExcelDataAsyncService.readXlsCacheAsyncMybatis(sheet, row, start, end, insertBuilder);

        }

    }

}

3、异步批量入库

@Async("async-executor")

public void readXlsCacheAsync(XSSFSheet sheet, XSSFRow row, int start, int end, StringBuilder insertBuilder) {

    StringBuilder stringBuilder = new StringBuilder();

    for (int i = start; i <= end; i++) {

        XSSFRow xssfRow = sheet.getRow(i);

        String id = "";

        String name = "";

        for (int j = 0; j < row.getPhysicalNumberOfCells(); j++) {

            if (j == 0) {

                id = xssfRow.getCell(j) + "";

            } else if (j == 1) {

                name = xssfRow.getCell(j) + "";

            }

        }



		// 先在读取Excel之前，缓存所有数据，再做判断

        boolean flag = isExisted(id, name);

        if (!flag) {

            stringBuilder.append(insertBuilder);

            stringBuilder.append('\'').append(uuid()).append('\'').append(",");

            for (int j = 0; j < row.getPhysicalNumberOfCells(); j++) {

                stringBuilder.append('\'').append(value).append('\'').append(",");

            }

            stringBuilder.deleteCharAt(stringBuilder.length() - 1);

            stringBuilder.append(" )").append("\n");

        }

    }



    List<String> collect = Arrays.stream(stringBuilder.toString().split("\n")).collect(Collectors.toList());

    if (collect != null && collect.size() > 0) {

        int sum = JdbcUtil.executeDML(collect);

    }

}



private boolean isExisted(String id, String name) {

    return ReadExcelCacheAsyncController.USER_INFO_SET.contains(id + "," + name);

}

4、异步线程池工具类

@Async的作用就是异步处理任务。

在使用@Async时，如果不指定线程池的名称，也就是不自定义线程池，@Async是有默认线程池的，使用的是Spring默认的线程池SimpleAsyncTaskExecutor。

默认线程池的默认配置如下：

从最大线程数可以看出，在并发情况下，会无限制的创建线程，我勒个吗啊。

也可以通过yml重新配置：

spring:

  task:

    execution:

      pool:

        max-size: 10

        core-size: 5

        keep-alive: 3s

        queue-capacity: 1000

        thread-name-prefix: my-executor

也可以自定义线程池，下面通过简单的代码来实现以下@Async自定义线程池。

@EnableAsync// 支持异步操作

@Configuration

public class AsyncTaskConfig {



    /**

     * com.google.guava中的线程池

     * @return

     */

    @Bean("my-executor")

    public Executor firstExecutor() {

        ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("my-executor").build();

        // 获取CPU的处理器数量

        int curSystemThreads = Runtime.getRuntime().availableProcessors() * 2;

        ThreadPoolExecutor threadPool = new ThreadPoolExecutor(curSystemThreads, 100,

                200, TimeUnit.SECONDS,

                new LinkedBlockingQueue<>(), threadFactory);

        threadPool.allowsCoreThreadTimeOut();

        return threadPool;

    }



    /**

     * Spring线程池

     * @return

     */

    @Bean("async-executor")

    public Executor asyncExecutor() {

        ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();

        // 核心线程数

        taskExecutor.setCorePoolSize(24);

        // 线程池维护线程的最大数量，只有在缓冲队列满了之后才会申请超过核心线程数的线程

        taskExecutor.setMaxPoolSize(200);

        // 缓存队列

        taskExecutor.setQueueCapacity(50);

        // 空闲时间，当超过了核心线程数之外的线程在空闲时间到达之后会被销毁

        taskExecutor.setKeepAliveSeconds(200);

        // 异步方法内部线程名称

        taskExecutor.setThreadNamePrefix("async-");



        /**

         * 当线程池的任务缓存队列已满并且线程池中的线程数目达到maximumPoolSize，如果还有任务到来就会采取任务拒绝策略

         * 通常有以下四种策略：

         * ThreadPoolExecutor.AbortPolicy:丢弃任务并抛出RejectedExecutionException异常。

         * ThreadPoolExecutor.DiscardPolicy：也是丢弃任务，但是不抛出异常。

         * ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列最前面的任务，然后重新尝试执行任务（重复此过程）

         * ThreadPoolExecutor.CallerRunsPolicy：重试添加当前的任务，自动重复调用 execute() 方法，直到成功

         */

        taskExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());

        taskExecutor.initialize();

        return taskExecutor;

    }

}

5、异步失效的原因

三、线程池中的核心线程数设置问题

有一个问题，一直没时间摸索，线程池中的核心线程数CorePoolSize、最大线程数MaxPoolSize，设置成多少，最合适，效率最高。

借着这个机会，测试一下。

1、我记得有这样一个说法，CPU的处理器数量

将核心线程数CorePoolSize设置成CPU的处理器数量，是不是效率最高的？

// 获取CPU的处理器数量

int curSystemThreads = Runtime.getRuntime().availableProcessors() * 2;

Runtime.getRuntime().availableProcessors()获取的是CPU核心线程数，也就是计算资源。

• CPU密集型，线程池大小设置为N，也就是和cpu的线程数相同，可以尽可能地避免线程间上下文切换，但在实际开发中，一般会设置为N+1，为了防止意外情况出现线程阻塞，如果出现阻塞，多出来的线程会继续执行任务，保证CPU的利用效率。


• IO密集型，线程池大小设置为2N，这个数是根据业务压测出来的，如果不涉及业务就使用推荐。

在实际中，需要对具体的线程池大小进行调整，可以通过压测及机器设备现状，进行调整大小。

如果线程池太大，则会造成CPU不断的切换，对整个系统性能也不会有太大的提升，反而会导致系统缓慢。

我的电脑的CPU的处理器数量是24。

那么一次读取多少行最合适呢？

测试的Excel中含有10万条数据，10万/24 = 4166，那么我设置成4200，是不是效率最佳呢？

测试的过程中发现，好像真的是这样的。

2、我记得大家都习惯性的将核心线程数CorePoolSize和最大线程数MaxPoolSize设置成一样的，都爱设置成200。

是随便写的，还是经验而为之？

测试发现，当你将核心线程数CorePoolSize和最大线程数MaxPoolSize都设置为200的时候，第一次它会同时开启150个线程，来进行工作。

这个是为什么？

3、经过数十次的测试

四、通过EasyExcel读取并插入数据库

EasyExcel的方式，我就不写双异步优化了，大家切记陷入低水平勤奋的怪圈。

1、ReadEasyExcelController

@RequestMapping(value = "/readEasyExcel", method = RequestMethod.POST)

@ResponseBody

public String readEasyExcel() {

    try {

        String path = "G:\\测试\\data\\";

        String[] xlsxArr = new File(path).list();

        for (int i = 0; i < xlsxArr.length; i++) {

            String filePath = path + xlsxArr[i];

            File fileTemp = new File(path + xlsxArr[i]);

            String fileName = fileTemp.getName().replace(".xlsx", "");

            List<UserInfo> list = new ArrayList<>();

            EasyExcel.read(filePath, UserInfo.class, new ReadEasyExeclAsyncListener(readEasyExeclService, fileName, batchCount, list)).sheet().doRead();

        }

    }catch (Exception e){

        logger.error("readEasyExcel 异常：",e);

        return "error";

    }

    return "suceess";

}

2、ReadEasyExeclAsyncListener

public ReadEasyExeclService readEasyExeclService;

	// 表名

    public String TABLE_NAME;

    // 批量插入阈值

    private int BATCH_COUNT;

    // 数据集合

    private List<UserInfo> LIST;



    public ReadEasyExeclAsyncListener(ReadEasyExeclService readEasyExeclService, String tableName, int batchCount, List<UserInfo> list) {

        this.readEasyExeclService = readEasyExeclService;

        this.TABLE_NAME = tableName;

        this.BATCH_COUNT = batchCount;

        this.LIST = list;

    }



    @Override

    public void invoke(UserInfo data, AnalysisContext analysisContext) {

        data.setUuid(uuid());

        data.setTableName(TABLE_NAME);

        LIST.add(data);

        if(LIST.size() >= BATCH_COUNT){

            // 批量入库

            readEasyExeclService.saveDataBatch(LIST);

        }

    }



    @Override

    public void doAfterAllAnalysed(AnalysisContext analysisContext) {

        if(LIST.size() > 0){

        	// 最后一批入库

            readEasyExeclService.saveDataBatch(LIST);

        }

    }



    public static String uuid() {

        return UUID.randomUUID().toString().replace("-", "");

    }

}

3、ReadEasyExeclServiceImpl

@Service

public class ReadEasyExeclServiceImpl implements ReadEasyExeclService {



    @Resource

    private ReadEasyExeclMapper readEasyExeclMapper;



    @Override

    public void saveDataBatch(List<UserInfo> list) {

    	// 通过mybatis入库

        readEasyExeclMapper.saveDataBatch(list);

        // 通过JDBC入库

        // insertByJdbc(list);

        list.clear();

    }

    

    private void insertByJdbc(List<UserInfo> list){

        List<String> sqlList = new ArrayList<>();

        for (UserInfo u : list){

            StringBuilder sqlBuilder = new StringBuilder();

            sqlBuilder.append("insert int0 ").append(u.getTableName()).append(" ( UUID,ID,NAME,AGE,ADDRESS,PHONE,OP_TIME ) values ( ");

            sqlBuilder.append("'").append(ReadEasyExeclAsyncListener.uuid()).append("',")

                            .append("'").append(u.getId()).append("',")

                            .append("'").append(u.getName()).append("',")

                            .append("'").append(u.getAge()).append("',")

                            .append("'").append(u.getAddress()).append("',")

                            .append("'").append(u.getPhone()).append("',")

                            .append("sysdate )");

            sqlList.add(sqlBuilder.toString());

        }



        JdbcUtil.executeDML(sqlList);

    }

}

4、UserInfo

@Data

public class UserInfo {



    private String tableName;



    private String uuid;



    @ExcelProperty(value = "ID")

    private String id;



    @ExcelProperty(value = "NAME")

    private String name;



    @ExcelProperty(value = "AGE")

    private String age;



    @ExcelProperty(value = "ADDRESS")

    private String address;



    @ExcelProperty(value = "PHONE")

    private String phone;

}

一、为什么要跨标签页通信

在web开发中，有时会有这样的情况，A页面中打开了B页面，B页面中操作了一些内容，再回到A页面时，需要看到更新后的内容。这种场景在电商、支付、社交等领域经常出现。

二、实现跨标签页通信的几种方式

2.1 localStorage

打开A页面，可以看到localStorage和sessionStorage中都存储了testA：

B页面中，可以获取到localStorage，但是无法获取到sessionStorage：

2.2 BroadcastChannel

BroadcastChannel允许同源下浏览器不同窗口订阅它，postMessage方法用于发送消息，message事件用于接收消息。

A页面：

      const bc = new BroadcastChannel('test')



      bc.postMessage('不去上班行吗？')

B页面：

      const bc = new BroadcastChannel('test')



      bc.onmessage = (e) => {

        console.log(e)

      }

2.3 postMessage（跨源通信）

2.3.1 iframe跨域数据传递

parent.html

<!DOCTYPE html>

<html>

  <head>

    <meta charset="utf-8" />

    <title></title>

  </head>

  <body>

    <h1>主页面</h1>

    <iframe id="child" src="http://10.7.9.69:8080"></iframe>

    <div>

      <h2>主页面跨域接收消息区域</h2>

      <div id="message"></div>

    </div>

  </body>

  <script>

    // 传递数据到子页面

    window.onload = function () {

      // 第二个参数表示哪个窗口可以接收到消息

      document.getElementById('child').contentWindow.postMessage('不上班行不行', 'http://10.7.9.69:8080')

    }

    // 接受子页面传递过来的数据

    window.addEventListener('message', function (event) {

      document.getElementById('message').innerHTML = '收到' + event.origin + '消息：' + event.data

    })

  </script>

</html>

App.vue

<template>

  <div class="app">

    <div id="message"></div>

  </div>

</template>

<script>

export default {

  created() {

    // 接收父页面传过来的数据

    window.addEventListener('message', function (event) {

      // 处理addEventListener执行两次的情况，避免获取不到data

      // 因此判断接收的域是否是父页面

      console.log('event', event)

      if (event.origin.includes('http://127.0.0.1:5501')) {

        document.getElementById('message').innerHTML = '收到' + event.origin + '消息：' + event.data

        // 把数据传递给父页面  window.parent === top

        window.parent.postMessage('不上班你养我啊', 'http://127.0.0.1:5501')

      }

    })

  },

}

</script>

注：

2.3.2 postMessage在window.open()中的使用

从网上下载了一个开源的项目，发现登录界面的验证码无论怎么刷新，显示的都是同一个，即使换一个浏览器也是相同的图形验证码，说一下解决bug的过程

😶修改前的源代码如下(部分代码)

import cn.hutool.captcha.*;

import lombok.RequiredArgsConstructor;



@Service

@RequiredArgsConstructor

public class AuthServiceImpl implements AuthService {



    private final AbstractCaptcha abstractCaptcha;

  

    @Override

    public CaptchaResult getCaptcha() {

        //获取验证码文本，例如 1+4=

        String captchaCode = abstractCaptcha.getCode();

        String imageBase64Data = abstractCaptcha.getImageBase64Data();

        

        String captchaKey = IdUtil.fastSimpleUUID();

        // 验证码文本缓存至Redis，用于登录校验

        redisTemplate.opsForValue().set(CacheConstants.CAPTCHA_CODE_PREFIX + captchaKey, captchaCode,captchaProperties.getExpireSeconds(), TimeUnit.SECONDS);

        //......

    }

}

😐分析上面的代码，首先作者使用了Lombok提供的@RequiredArgsConstructor注解，它的作用是为下面被 final 修饰的变量生成构造方法，即利用构造方法将AbstractCaptcha对象注入到Spring容器中，但是通过这种方式注入，默认情况下Bean是单例的，即多次请求会复用同一个Bean 。

😐其次，阅读hutool有关abstractCaptcha.getCode()部分的代码，如下，可以看到，在第一次生成code时，就将生成的code赋值给了成员变量 code,再结合前面的单例Bean，真相大白。

//验证码

protected String code;



@Override

public String getCode() {

   if (null == this.code) {

      createCode();

   }

   return this.code;

}



@Override

public void createCode() {

   generateCode();



   final ByteArrayOutputStream out = new ByteArrayOutputStream();

   ImgUtil.writePng(createImage(this.code), out);

   this.imageBytes = out.toByteArray();

}



//生成验证码字符串

protected void generateCode() {

   this.code = generator.generate();

}

😎最终修改业务代码如下

import cn.hutool.captcha.*;

import cn.hutool.captcha.generator.MathGenerator;

import lombok.RequiredArgsConstructor;



@Service

@RequiredArgsConstructor

public class AuthServiceImpl implements AuthService {



    //private final AbstractCaptcha abstractCaptcha; 

  

    @Override

    public CaptchaResult getCaptcha() {

        ShearCaptcha captcha = CaptchaUtil.createShearCaptcha(200, 45, 4, 4);

        // 自定义验证码内容为四则运算方式

        captcha.setGenerator(new MathGenerator(1));

        String captchaCode = captcha.getCode();

        String captchaBase64 = captcha.getImageBase64Data();

        

        String captchaKey = IdUtil.fastSimpleUUID();

        // 验证码文本缓存至Redis，用于登录校验

        redisTemplate.opsForValue().set(CacheConstants.CAPTCHA_CODE_PREFIX + captchaKey, captchaCode,captchaProperties.getExpireSeconds(), TimeUnit.SECONDS);

        //......

    }

}

😴阅读hutool关于createShearCaptcha()方法的源码，每次调用都会new一个新对象

/**

 * 创建扭曲干扰的验证码，默认5位验证码

 *

 * @param width     图片宽

 * @param height    图片高

 * @param codeCount 字符个数

 * @param thickness 干扰线宽度

 * @return {@link ShearCaptcha}

 * @since 3.3.0

 */

public static ShearCaptcha createShearCaptcha(int width, int height, int codeCount, int thickness) {

   return new ShearCaptcha(width, height, codeCount, thickness);

}