❝

工欲善其事必先利其器，使用过内网开发的小伙伴都知道，CV大法在内网基本就废了，查资料也是非常的不便。对于一名程序员来说，如果把搜索引擎和CV键给他ban了，遇到问题后那基本是寸步难行。今天给大家介绍几种帮助内网开发提效的方法，希望能够帮助到大家。

一、文档站点内网部署

可以把项目中所用技术和框架的文档部署到公司内网中。

以elementPlus为例：

1、访问gh-pages分支https://github.com/element-plus/element-plus/tree/gh-pages，下载文档站源码。

2、将文档站部署到内网服务器（以nginx为例）。

    server {

        listen       9800;

        server_name  localhost;



        location / {

            root   html/element-plus-gh-pages;

            index  index.html index.htm;

            try_files $uri $uri/ /element-plus-gh-pages/index.html;

        }



        error_page   500 502 503 504  /50x.html;

        location = /50x.html {

            root   html;

        }

    }

部署后的访问速度也是非常快的

使用这种方式，随着部署的站点增多，后续框架、文档更新的时候，维护起来相对是比较麻烦的。且只能查看文档，遇到问题需要求助度娘还是不太方便。

下面介绍两种物理外挂，可以直接访问外网。

二、USB跨屏穿越器数据线

个人感觉此方案的体验是最好的，缺点是需要两台电脑，并且需要花钱买一根线，价格在80-200之间。

购买

某宝、某鱼都有销售，我是在某宝85块买的。

使用

连接两台电脑的USB端口即可，会自动安装驱动，那根线实际上就相当于是一个文件中转器，可以实现剪切板、文件的互传。使用体验就跟一台电脑连接了两台显示器一样。如下图所示：

三、手机投屏

本文重点介绍此方案，因为可以白嫖且不需要第二台电脑。一部安卓手机+数据线即可，缺点是文件传输不太方便。它就是一个开源投屏项目scrcpy。可以看到，此项目在github上拥有高达102k的star数量。

✨亮点

• 亮度 （原生，仅显示设备屏幕）


• 表演 （30~60fps）


• 质量 （1920×1080或以上）


• 低延迟 （70~100ms）


• 启动时间短 （显示第一张图像约1秒）


• 非侵入性 （设备上没有安装任何东西）


• 不需要 ROOT


• 有线无线都可连接


• 可以随便调整界面和码率


• 画面随意裁剪，自带录屏（手游直播利器）


• 支持多设备同时投屏


• 利用电脑的键盘和鼠标可以控制手机


• 把 APK 文件拖拽到电脑窗口即可安装应用到手机，把普通文件拖拽到窗口即可复制到手机


• 手机电脑共享剪贴板


• 自动检测USB连接的设备


• 可直接添加设备的局域网IP，达到无线控制的效果


• 将自动保存连接过的IP地址，下次输入时，自动提醒


• 支持设备别名


• 支持中英两种语言


• Tray menu


• 等等等...

安装

根据不同系统直接去release页面下载对应版本即可：github.com/Genymobile/…

使用

下载解压完，进入软件目录，点击下图按钮打开命令行界面，输入启动命令即可。

命令行输入scrcpy，按回车， 猿神，起洞！

启动之后，即可使用鼠标操作手机，非常的丝滑

1、手机复制文本到电脑

2、电脑复制文本到手机

可以看到，使用投屏的方式，也可以实现CV大法。并且可以使用手机端的外网搜索资料、解决问题等。以下是该项目的快捷键，熟练使用，即可达到人机合一的地步。

快捷键

使用小技巧

经过笔者几天的使用，总结出几个小技巧。

1、电脑键盘控制手机进行中文输入，必须使用正确的输入法组合。

手机端：讯飞输入法(搜狗输入法不支持)

电脑端：ENG(使用英文键盘)

2、手机熄屏状态下投屏。 在scrcpy命令后加上熄屏参数即可：scrcpy --turn-screen-off

这样就可以在手机熄屏的状态下，仍可以被电脑操作，达到节省电量和减轻发热的目的。

诸如此类的命令参数还有很多，执行scrcpy --help就可查看详细的帮助文档。

衍生项目

因为开源的特性，scrcpy也衍生了一些相关项目，列举其中一些：

• QtScrcpy 使用qt重新实现的桌面端，并加强了对游戏的支持。


• scrcpy-gui 为scrcpy的命令行提供了gui界面。


• guiscrcpy 另一个scrcpy的gui界面。


• scrcpy-docker docker版本的scrcpy。


• scrcpy-go go语言版本的scrcpy，增强对游戏的支持。

总结

第二第三种方法虽然建立了内网开发电脑和外网设备的联系，但是是不会被公司的安全系统检测到一机双网的，因为其本质就类似于设计模式中的发布订阅模式，用数据线充当了中间人，两台设备之间方便传输数据了而已，不会涉及到联网。

内网开发的痛点，无非就是复制粘贴、文件传输不便，只要打通这个链路，就能解决此问题。以上三个方法，笔者在实际工作中都用到了，确实极大的提高了工作效率。如果你也在饱受内网开发的折磨，不妨试试这几个方法。

独立开发者解放思维，开放眼界真的很有必要。就算自己一时没有好的 idea，也可以多观察学习一些（成功的）非主流的独立产品。我之前写文说过独立开发有死亡加速三件套：笔记、记账、todo。但是不得不说我还是保守了，俗话说的好：勇敢的人先享受世界。既然我单个产品都没优势，那我 all in one，把笔记、记账、待办都做到一个 app 里行不行？

直觉上我感觉这样不行吧？但是，啊？

原来真有人吃粉会点全家福啊。于是我想你做是能做但是用户就会喜欢吗？

我直接一个好家伙，两千多评价，4.7分！

嫉妒使我面目全非了。看了一下会员价格，买断28。这个 app 在没有苹果推荐的情况下，做到了两千多评价，我估计用户数大于 5 万。我看了一下上线时间，这个 app 前后开发持续了一年多的时间。如果我按照付费转化10%算，那么这个 app 扣掉 15% 苹果渠道费后收入大概有 12 万（50000 * 10% * 28 * 0.85）。但是这个 app 如果运营得当，后面还是会有新用户进来。因为app是极简（没有设计师的委婉说法），设计成本几乎没有。以当下的数据看，算是回本了。后面再来的增长都是利润了。

定位分析：笔记、待办、记账是很主流的用户需求，但是也有很多入门用户都只有很轻度的需求，垂直的 app 都太专业了，如果我想要这些数据在一起，很轻量，没有广告，设计简洁，又一次买断，那么市场上就没有对应的产品。

完成这个app 有两个难点：首先你要判断市场有这么一块空白，第二个难点，因为任何一个单点都没有优势，怎样触达目标用户。

我看了作者的小红书，他选择了一个很新颖的切入点：学生群体。他有一个宣传口号是“专注学生自律养成的工具 app”。学生群体不会有特别重度的需求，又集中，因为付费转化有限所以垂类专业app都不太考虑学生群体，在这个用户定位这个app又找到了独特的切入点。

这个定位有多重要呢，这个帖子带来的用户下载量就能达到 10000。

总的来说，这个 app 给我带来了很大的震撼。希望也能给大家带来启发。

前言

最近闲来没事，一直在掘金上摸鱼，看了不少高并发相关的文章，突然有感而发，想到了几年前做的一个项目，也多少和高并发有点关系。

这里我一边回忆落地细节一边和大家分享下，兴许能给大家带来点灵感。

正文

需求及背景

先来介绍下需求，首先项目是一个志愿填报系统。

核心功能是两块，一是给考试填报志愿，二是给老师维护考生数据。

本来这个项目不是我们负责，奈何去年公司负责这个项目的组遭到了甲方严重的投诉，说很多考生用起来卡顿，甚至把没填上志愿的责任归到系统上。

甲方明确要求，如果这年再出现这种情况，公司在该省的所有项目将面临被替换的风险。

讨论来讨论去，最后公司将任务落到我们头上时，已经是几个月后的事了，到临危受命阶段，剩下不到半年时间。

虽然直属领导让我们不要有心理负担，做好了表扬，做不好锅也不是我们的，但明显感觉到得到他的压力，毕竟一个不小心就能上新闻。

分析

既然开始做了，再说那些有的没的就没用了，直接开始分析需求。

首先，业务逻辑并不算复杂，难点是在并发和数据准确性上。与客户沟通后，大致了解了并发要求后，于是梳理了下。

方案研讨

接下来我会从当时我们切入问题的点开始，从前期设计到项目落地整个过程的问题及思考，一步步去展示这个项目如何实现的

首先，我们没有去设计表，没有去设计接口，而是先去测试。测试什么？测试我们需要用到或可能用到的中间件是否满足需求

MySQL

首先是MySQL，单节点MySQL测试它的读和取性能，新建一张user表。

向里面并发插入数据和查询数据，得到的TPS大概在5k，QPS大概在1.2W。

查询的时候是带id查询，索引列的查询不及id查询，差距大概在1k。

insert和update存在细微并发差距，但基本可以忽略，影响更新性能目前最大的问题是索引。

如果表中带索引，将降低1k-1.5k的TPS。

目前结论是，mysql不能达到要求，能不能考虑其他架构，比如mysql主从复制，写和读分开。

测试后，还是放弃，主从复制结构会影响更新，大概下降几百，而且单写的TPS也不能达到要求。

至此结论是，mysql直接上的方案肯定是不可行的

Redis

既然MySQL直接查询和写入不满足要求，自然而然想到加入redis缓存。于是开始测试缓存，也从单节点redis开始测试。

get指令QPS达到了惊人的10w，set指令TPS也有8W，意料之中也惊喜了下，仿佛看到了曙光。

但是，redis容易丢失数据，需要考虑高可用方案

实现方案

既然redis满足要求，那么数据全从redis取，持久化仍然交给mysql，写库的时候先发消息，再异步写入数据库。

最后大体就是redis + rocketMQ + mysql的方案。看上去似乎挺简单，当时我们也这样以为 ，但是实际情况却是，我们过于天真了。

这里主要以最重要也是要求最高的保存志愿信息接口开始攻略

故障恢复

第一个想到的是，这些个节点挂了怎么办？

mysql挂了比较简单，他自己的机制就决定了他即使挂掉，重启后仍能恢复数据，这个可以不考虑。

rocketMQ一般情况下挂掉了可能会丢失数据，经过测试发现，在高并发下，确实存在丢消息的现象。

原因是它为了更加高效，默认采用的是异步落盘的模式，这里为了保证消息的绝对不丢失，修改成同步落盘模式。

然后是最关键的redis，不管哪种模式，redis在高并发下挂掉，都会存在丢失数据的风险。

数据丢失对于这个项目格外致命，优先级甚至高于并发的要求。

于是，问题难点来到了如何保证redis数据正确，讨论过后，决定开启redis事务。

保存接口的流程就变成了以下步骤：

1.redis 开启事务，更新redis数据

2.rocketMQ同步落盘

3.redis 提交事务

4.mysql异步入库

我们来看下这个接口可能存在的问题。

第一步，如果redis开始事务或更新redis数据失败，页面报错，对于数据正确性没有影响

第二步，如果rocketMQ落盘报错，那么就会有两种情况。

情况一，落盘失败，消息发送失败，好像没什么影响，直接报错就可。

情况二，如果发送消息成功，但提示发送失败（无论什么原因），这时候将导致mysql和redis数据的最终不一致。

如何处理？怎么知道是redis的有问题还是mysql的有问题？出现这种情况时，如果考生不继续操作，那么这条错误的数据必定无法被更新正确。

考虑到这个问题，我们决定引入一个时间戳字段，同时启动一个定时任务，比较mysql和redis不一致的情况，并自主修复数据。

首先，redis中记录时间戳，同时在消息中也带上这个时间戳并在入库时记录到表中。

然后，定时任务30分钟执行一次，比较redis中的时间戳是否小于mysql，如果小于，便更新redis中数据。如果大于，则不做处理。

同时，这里再做一层优化，凌晨的时候执行一个定时任务，比较redis中时间戳大于mysql中的时间戳，连续两天这条数据都存在且没有更新操作，将提示给我们手动运维。

然后是第三步，消息提交成功但是redis事务提交失败，和第二步处理结果一致，将被第二个定时任务处理。

这样看下来，即使redis崩掉，也不会丢失数据。

第一轮压测

接口实现后，当时怀着期待，信息满满的去做了压测，结果也是当头棒喝。

首先，数据准确性确实没有问题，不管突然kill掉哪个环节，都能保证数据最终一致性。

但是，TPS却只有4k不到的样子，难道是节点少了？

于是多加了几个节点，但是仍然没有什么起色。问题还是想简单了。

重新分析

经过这次压测，之后一个关键的问题被提了出来，影响接口TPS的到底是什么？？？

一番讨论过后，第一个结论是：一个接口的响应时间，取决于它最慢的响应时间累加，我们需要知道，这个接口到底慢在哪一步或哪几步？

于是用arthas看了看到底慢在哪里？

结果却是，最慢的竟然是redis修改数据这一步！这和测试的时候完全不一样。于是针对这一步，我们又继续深入探讨。

结论是：

redis本身是一个很优秀的中间件，并发也确实可以，选型时的测试没有问题。

问题出在IO上，我们是将考生的信息用json字符串存储到redis中的（为什么不保存成其他数据结构，因为我们提前测试过几种可用的数据结构，发现redis保存json字符串这种性能是最高的），

而考生数据虽然单条大小不算大，但是在高并发下的上行带宽却是被打满的。

于是针对这种情况，我们在保存到redis前，用gzip压缩字符串后保存到redis中。

为什么使用gzip压缩方式，因为我们的志愿信息是一个数组，很多重复的数据其实都是字段名称，gzip和其他几个压缩算法比较后，综合考虑到压缩率和性能，在当时选择了这种压缩算法。

针对超过限制的字符串，我们同时会将其拆封成多个（实际没有超过三个的）key存储。

继续压测

又一轮压测下来，效果很不错，TPS从4k来到了8k。不错不错，但是远远不够啊，目标2W，还没到它的一半。

节点不够？加了几个节点，有效果，但不多，最终过不了1W。

继续深入分析，它慢在哪？最后发现卡在了rocketMQ同步落盘上。

同步落盘效率太低？于是压测一波发现，确实如此。

因为同步落盘无论怎么走，都会卡在rocketMQ写磁盘的地方，而且因为前面已经对字符串压缩，也没有带宽问题。

问题到这突然停滞，不知道怎么处理rocketMQ这个点。

同时，另一个同事在测试查询接口时也带来了噩耗，查询接口在1W2左右的地方就上不去了，原因还是卡在带宽上，即使压缩了字符串，带宽仍被打满。

怎么办？考虑许久，最后决定采用较常规的处理方式，那就是数据分区，既然单个rocketMQ服务性能不达标，那么就水平扩展，多增加几个rocketMQ。

不同考生访问的MQ不一样，同时redis也可以数据分区，幸运的是正好redis有哈希槽的架构支持这种方式。

而剩下的问题就是如何解决考生分区的方式，开始考虑的是根据id进行求余的分区，但后来发现这种分区方式数据分布及其不均匀。

后来稍作改变，根据正件号后几位取余分区，数据分布才较为均匀。有了大体解决思路，一顿操作后继续开始压测。

一点小意外

压测之后，结果再次不如人意，TPS和QPS双双不增反降，继续通过arthas排查。

最后发现，redis哈希槽访问时会在主节点先计算key的槽位，而后再将请求转到对应的节点上访问，这个计算过程竟然让性能下降了20%-30%。

于是重新修改代码，在java内存中先计算出哈希槽位，再直接访问对应槽位的redis。如此重新压测，QPS达到了惊人的2W，TPS也有1W2左右。

不错不错，但是也只到了2W，在想上去，又有了瓶颈。

不过这次有了不少经验，马上便发现了问题所在，问题来到了nginx，仍然是一样的问题，带宽！

既然知道原因，解决起来也比较方便，我们将唯一有大带宽的物理机上放上两个节点nginx，通过vip代理出去，访问时会根据考生分区信息访问不同的地址。

压测

已经记不清第几轮压测了，不过这次的结果还算满意，主要查询接口QPS已经来到了惊人的4W，甚至个别接口来到6W甚至更高。

胜利已经在眼前，唯一的问题是，TPS上去不了，最高1W4就跑不动了。

什么原因呢？查了每台redis主要性能指标，发现并没有达到redis的性能瓶颈（上行带宽在65%，cpu使用率也只有50%左右）。

MQ呢？MQ也是一样的情况，那出问题的大概率就是java服务了。分析一波后发现，cpu基本跑到了100%，原来每个节点的最大链接数基本占满，但带宽竟然还有剩余。

静下心来继续深入探讨，连接数为什么会满了？原因是当时使用的SpringBoot的内置容器tomcat，无论如何配置，最大连接数最大同时也就支持1k多点。

那么很简单的公式就能出来，如果一次请求的响应时间在100ms，那么1000 * 1000 / 100 = 10000。

也就是说单节点最大支持的并发也就1W，而现在我们保存的接口响应时间却有300ms，那么最大并发也就是3k多，目前4个分区，看来1W4这个TPS也好像找到了出处了。

接下来就是优化接口响应时间的环节，基本是一步一步走，把能优化的都优化了一遍，最后总算把响应时间控制在了100ms以内。

那么照理来说，现在的TPS应该会来到惊人的4W才对。

再再次压测

怀着忐忑又激动的心情，再一次进入压测环节，于是，TPS竟然来到了惊人的2W5。

当时真心激动了一把，但是冷静之后却也奇怪，按正常逻辑，这里的TPS应该能达到3W6才对。

为了找到哪里还有未发现的坑（怕上线后来惊喜），我们又进一步做了分析，最后在日志上找到了些许端倪。

个别请求在链接redis时报了链接超时，存在0.01%的接口响应时间高于平均值。

于是我们将目光投向了redis连接数上，继续一轮监控，最终在业务实现上找到了答案。

一次保存志愿的接口需要执行5次redis操作，分别是获取锁、获取考生信息、获取志愿信息、修改志愿信息、删除锁，同时还有redis的事务。

而与之相比，查询接口只处理了两次操作，所以对于一次保存志愿的操作来看，单节点的redis最多支持6k多的并发。

为了验证这个观点，我们尝试将redis事务和加锁操作去掉，做对照组压测，发现并发确实如预期的一样有所提升（其实还担心一点，就是抢锁超时）。

准备收工

至此，好像项目的高并发需求都已完成，其他的就是完善完善细节即可。

于是又又又一次迎来了压测，这一次不负众望，重要的两个接口均达到了预期。

这之后便开始真正进入业务实现环节，待整个功能完成，在历时一个半月带两周的加班后，终于迎来了提测。

提测后的问题

功能提测后，第一个问题又又又出现在了redis，当高并发下突然kill掉redis其中一个节点。

因为用的是哈希槽的方式，如果挂掉一个节点，在恢复时重新算槽将非常麻烦且效率很低，如果不恢复，那么将严重影响并发。

于是经过讨论之后，决定将redis也进行手动分区，分区逻辑与MQ的一致。

但是如此做，对管理端就带来了一定影响，因为管理端是列表查询，所以管理端获取数据需要从多个节点的redis中同时获取。

于是管理端单独写了一套获取数据分区的调度逻辑。

第二个问题是管理端接口的性能问题，虽然管理端的要求没考生端高，但扛不住他是分页啊，一次查10个，而且还需要拼接各种数据。

不过有了前面的经验，很快就知道问题出在了哪里，关键还是redis的连接数上，为了降低链接数，这里采用了pipeline拼接多个指令。

上线

一切准备就绪后，就准备开始上线。说一下应用布置情况，8+4+1+2个节点的java服务，其中8个节点考生端，4个管理端，1个定时任务，2个消费者服务。

3个ng，4个考生端，1个管理端。

4个RocketMQ。

4个redis。

2个mysql服务，一主一从，一个定时任务服务。

1个ES服务。

最后顺利上线，虽然发生了个别线上问题，但总体有惊无险，

而真是反馈的并发数也远没有到达我们的系统极限，开始准备的水平扩展方案也没有用上，无数次预演过各个节点的宕机和增加分区，一般在10分钟内恢复系统，不过好在没有排上用场。

最后

整个项目做下来感觉越来越偏离面试中的高并发模式，说实在的也是无赖之举，

偏离的主要原因我认为是项目对数据准确性的要求更高，同时需要完成高并发的要求。

但是经过这个项目的洗礼，在其中也收获颇丰，懂得了去监控服务性能指标，然后也加深了中间件和各种技术的理解。

做完之后虽然累，但也很开心，毕竟在有限的资源下去分析性能瓶颈并完成项目要求后，还是挺有成就感的。

再说点题外话，虽然项目成功挽回了公司在该省的形象，也受到了总公司和领导表扬，但最后也就这样了，

实质性的东西一点没有，这也是我离开这家公司的主要原由。不过事后回想，这段经历确实让人难忘，也给我后来的工作带来了很大的帮助。

从以前的crud，变得能去解决接口性能问题。这之前一遇上，可能两眼茫然或是碰运气，现在慢慢的会根据蛛丝马迹去探究优化方案。

不知道我在这个项目的经历是否能引起大家共鸣？希望这篇文章能对你有所帮助。

前言

想着给自己的博客每年一个置顶帖子，于是便有了此文。

1. 博主的自我介绍

我是一名Java开发工作者，20年大学毕业，专业：计算机科学与技术。

当年高考填报志愿的时候，计算机是一个新兴的蓬勃发展的行业，当时选择这个专业的原因时：一是想着毕业之后进入到这个行业从事相关工作，二是想着这个专业在公务员报考中能报考的岗位也很多。但是大四规划未来人生方向的时候，市场给我们开了一个大大的玩笑，互联网行业乱成了一锅粥，有一句话叫做万物皆可转码，再加之培训班疯狂的向社会输送程序员，市场乱象频频发生，培训班出来的新人能把自己包装成4年5年工作经验，然后各个公司为了能降低用人成本，也为了节省培养新人的时间和开支，也是只招聘工作经验大于3、4年以上的程序员，导致市场对于应届生的接收程度极差，都不愿意招聘应届生，班里的很多学生该培训的培训，该考研考公的备考，该转行的转行....

这个时期能走的路只有三条

• 考研 毕业成为大厂码农 （幻想的）


• 考公


• 和现在就成为码农。

考研呢，也考了，大四下半学期备战了半年，怎么说呢，结果不意外，对自己的认知有偏差，如果能报考一个相对稳妥的双非本科，现在说必定也是一个失业的研究生呢，但是收获最少我把计算机四大件（数据结构、计算机网络、操作系统、计算机组成原理）背了个底朝天，也算是在将近毕业的时候努力的学习了一把大学专业基础的知识。

考公呢，那时候我莫名觉得考公绝对不行，当时运筹帷幄，指点江山，告知自己，现在体制内的各种发生的事情和情况导致未来的公务员绝对不是铁饭碗，加之公务员工资毕竟不像成为程序员肉眼可见的工资那么可观，于是果断的放弃了考公务员，真的，现在有巴掌我第一个扇回去。当时可是20年呀，公务员真的不是很卷，你看看现在，后悔 ....

考研失败之后还是找了个互联网的厂子，现在从事这个行业也有三四年时间了，但是行业的前景却并不像七八年前那样的好。

2、2023年

2023年对我来说绝对是人生最重要的一年之一。

上半年是我老婆人生中最重要的时期之一，她面临着毕业压力（一度让她面临抑郁和崩溃，可能你们会说不就是毕业嘛，哪有那么夸张，我只能说每个人的情况不一样，希望你们一辈子也不要遇见像她导师那样的人...）。

正在外边商场吃饭，然后接到导师电话开始开临时组会。

我们如履薄冰，战战兢兢度过了这段时间。终于，在六月份，她顺利毕业了（万幸）。

（顺利毕业）

（surprise）

七月，她也找到了人生中的第一份工作，我们的生活开始步入正轨。

同样七月终于拥有了人生第一辆车。

（开心）

在家人和我们自己的决定下，我们如期在十月订婚了。这对我们来说是非常重要的一步。

（去银行买的金条，打的金镯子，很划算哈 ~）

（自己买的订婚现场的装饰，pdd 买的，至今为止，我还是觉得我布置的最好看。）

（怎么样呀？jym）

（家人们，教你们一招 五粮液、软华子直接拿下老丈人）

（订婚现场，主持人是我一个妹妹，这张图能看清我桌子上都摆了啥，当天我没拍桌子。）

（订婚书一签，你可不就是我的人了 ~）

（直接拿下）

（小样，还想跑）

（往后余生，我们一起走）

本以为人生会一帆风顺地继续下去，但工作没多久，因为是制造业，厂里的有毒气体使得她呼吸道和身体都在变差，她不得不选择辞职（裸辞）。23年的社会结构变迁使得学历贬值，大学生人数的激增导致工作变得更加稀缺，失业潮开始席卷。

老婆从失业到现在一直住在我租的小房间里，但是我相信人生不可能总是一帆风顺的。

3、技术成长

除了完成基本的工作业务（今年也上线了 3个web网站 和 3个小程序）之外的技术栈扩充：

• 学习了 SpringBoot3.0 和 对应的 Spring 的生态。比如 SpringSecurity 6.0 以上 ...


• 还有 Java 17 的一些新特性和性能。


• 学习了 C# 和 .Net (只能说和 Java 很像，补全版的Java)，正在用C# 做了一个对接 OpenAI的一个类似 ChatGpt 一样的对话类的网站。（还不是很熟，但是能写了，面向百度编程）


• 学习了 领域驱动 DDD ，真的感觉要长脑子了，很多系统性的东西在慢慢融合。


• 接触了 Vue3 和 TypeScript （嗯，万物都在往面向对象发展 ~）


• 可以从 需求制定，域名、服务器、云服务 产品的选型，技术选型，前后端开发，部署上线，性能优化，中间件搭建，后期的运维测试。都能自己一个人搞下来了。（还是勉勉强强，但是按照我们现在这种模式的话，稍微简单一点的服务还是没啥问题的、单体服务就更没问题了。没错，我就是小公司全能手）


• 现在 Python 和 Shell 脚本 玩得 6 的一 。（脚本真方便，而且这种解释器语言真好用~）

4、个人成长

这一年中，有一丝丝的人生感悟，分享给大家。

在工作上，大家都知道，写代码到一定程度会有质的飞跃。今年我在工作方面有了一些感悟，但随着对知识的深入，我也意识到自己所不知道的更多。我从最基础的 Java、数据库和 Web 开发开始，逐渐深入研究技术，包括 Java、系统设计和架构、各种数据库进阶以及项目管理，然后扩展到安全与性能优化、沟通能力、业务和行业理解，以及技术趋势和新技术。然而，最近我意识到，一切都归结于一个道理：先做人，再做事。懂得做人，任何问题都能迎刃而解。我对此有些许领悟。

在工作中，技术的学习和提升固然至关重要，但随着不断的实践，我逐渐意识到成功并不仅取决于技术能力，更关键的是人格魅力和人际交往能力。我开始认识到要从意识开始转变。

从最开始的技术基础学习，到技术的深入研究，再到全面提升，这是职业发展的必经之路。但是当在职场中积累了一定经验后，我渐渐明白技术只是成功的一部分。在实际工作中，需要与人打交道、管理团队、协调资源，这些都需要更多的人际关系、沟通技巧和领导力。虽然我现在还在追求进步，但这是必经之路。

要学会做人，在职场上就意味着有坚定的原则和良好的职业道德。这意味着以诚实、正直、宽容的态度对待他人，学会尊重和理解他人的不同，善于倾听，愿意分享和帮助他人。

此外，学会做人也包括与同事的良好合作、与上级的有效沟通、与下属的关心和激励。建立良好的人际关系，培养团队合作精神。

我曾听过这样一段话，我们这一代，因为互联网的高速发展，能轻易接触到信息，就以为自己掌握了很多，但这个世界上真正有价值的东西都需付出等价的代价。先学会做人，再学做事。

5、总结与展望

新的一年：

• 常回家看看，暂时定的两个月最少回去一次吧。


• 好好给老婆准备明年春招。


• 好好写一些博客，将自己的技术分享出来。将自己的博客好好运营一下。


• 好好吃饭、锻炼，我实在是太瘦了，身体是革命的本钱。


• 交易，看看大A水有多深。兄弟们 2700 抄底了~


• 攒点钱，再去一次 汉中-留坝县自驾游。


• 抽时间把婚纱照拍了~

什么都会过去的，抓住现在，不是吗？

（我的头像，在汉中狮子沟牧场拍的）

（开心最重要，不是吗？）

（去年全球总决赛[ wbg vs t1]的时候线下场馆拍的，笑死 ~）

（前几天下雪 恐龙 vs 鸭子）

就这些，希望明年年度总结的时候可以将这些都完成 ~

引用《人世间》种的一句话：

从你出生的那一刻起, 端什么碗,吃什么饭, 经历什么事,什么时候和谁结婚, 都是定数。 别太难为自己,顺其自然就好。 人生的剧本, 你早在天堂就看过了, 你之所以选择这个剧本是因为, 这一生中有你认为值得的地方。

jym 加油 ！

背景

最近在开发H5，ui稿给的border：1px solid,因为ui稿上的宽度是750px，我们运行的页面宽度是375px，所以我们需要把所以尺寸/2。所以我们可能会想写border：0.5px solid。但是实际上，我们看页面渲染，仍然是渲染1px而不是0.5

示例代码

<!DOCTYPE html>

<html lang="en">

  <head>

    <meta charset="UTF-8" />

    <meta name="viewport" content="width=device-width, initial-scale=1.0" />

    <style>

      * {

        margin: 0;

        padding: 0;

        box-sizing: border-box;

      }



      body {

        font-family: Arial, sans-serif;

      }



      .flex {

        display: flex;

      }

      .item {

        margin-right: 10px;

        padding: 10px;

        font-size: 13px;

        line-height: 1;

        background-color: rgba(242, 243, 245,1);

      }

      .active {

        color: rgba(250, 100, 0, 1);

        font-size: 14px;

        border: 0.5px solid ;

      }

    </style>

  </head>

  <body>

    <div class="flex">

      <!-- <div class="item active">

        active

      </div> -->

      <div class="item">

        item1

      </div>

      <div class="item">

        item2

      </div>

      <div class="item">

        item3

      </div>

    </div>

  </body>

</html>

在没active的情况下

他们的内容都是占13px

在有active的情况下

active占了14px这个是没问题的，因为它font-size是14px嘛，但是我们是设置了border的宽度是0.5px，但展现的却是1px。

再来看看item

它内容占了16px，它受到相邻元素影响是14px+2px的上下边框

为啥border是1px呢

在 CSS 中，边框可以设置为 0.5px，但在某些情况下，尤其是低分辨率的屏幕上，浏览器可能会将其渲染为 1px 或根本不显示。这是因为某些浏览器和显示设备不支持小于 1px 的边框宽度或不能准确渲染出这样的细小边框。

浏览器渲染机制

• 不同浏览器对于小数像素的处理方式不同。一些浏览器可能会将 0.5px 边框四舍五入为 1px，以确保在所有设备上的一致性。

设备像素比

• 在高 DPI（如 Retina 显示器）设备上，0.5px 边框可能看起来更清晰，因为这些设备可以渲染更细的边框。


• 在低 DPI 设备上，0.5px 边框可能会被放大或者根本不会被显示。

解决办法

方法一：使用伪类和定位

.active {

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  position: relative;

}

.active::after {

  content: "";

  pointer-events: none;

  display: block;

  position: absolute;

  left: 0;

  top: 0;

  transform-origin: 0 0;

  border: 1px #ff892e solid;

  box-sizing: border-box;

  width: 100%;

  height: 100%;

}

另外的item的内容高度也是14px了符合要求

方法二：使用阴影，使用F12看的时候感觉还是有些问题

.active2 {

  margin-left: 10px;

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  position: relative;

  box-shadow: 0 0 0 0.5px #ff892e;

}

方法三：使用svg，但这种自己设置了宽度。

<div class="active">

  <svg width="100%" height="100%" viewBox="0 0 100 100" preserveAspectRatio="none">

    <rect x="0" y="0" width="100" height="100" fill="none" stroke="#ff892e" stroke-width="0.5"></rect>

  </svg>

  active

</div>

方案四：使用svg加定位，也比较麻烦，而且有其他的问题

<div class="active">

    <svg viewBox="0 0 100 100" preserveAspectRatio="none">

        <rect x="0" y="0" width="100" height="100" fill="none" stroke="#ff892e" stroke-width="0.5"></rect>

    </svg>

    <div class="content">active</div>

</div>

.active {

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  position: relative;

  display: inline-block; 

}

.active svg {

  position: absolute;

  top: 0;

  left: 0;

  width: 100%;

  height: 100%;

  pointer-events: none; 

  box-sizing: border-box;

}

.active .content {

  position: relative;

  z-index: 1; 

}

方法五：使用一个父元素 比较麻烦

<div class="border-container">

  <div class="active">active</div>

</div>



.border-container {

  display: inline-block;

  padding: 0.5px; 

  background-color: #ff892e; 

}



.active {

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  background-color: white; 

}

最后

在公司里，我们使用的都是方案一，这样active和item它们的内容高度都是14px了。然后我们再给他们的父盒子加上 align-items: center。这样active的高度是14px，其他都是13px了。但是active的高度会比其他item的盒子高1px，具体看个人需求是否添加吧。

1、背景

前两天老板找到我说有一个需求，要求使用英雄联盟的人物动画制作一个加载中的组件，类似于下面这样：

我定眼一看：这个可以实现，但是需要UI妹子给切图。

老板：UI？ 咱们啥时候招的UI !

我：老板，那不中呀，不切图弄不成呀。

老板：下个月绩效给你A。

我：那中，管管管。

2、调研

发动我聪明的秃头，实现这个需求有以下几种方案：

• 切动画帧，没有UI不中❎。


• 去lol客户端看看能不能搞到什么美术素材，3D模型啥的，可能行❓


• 问下 gpt4o，有没有哪个老表收集的有lol英雄的美术素材，如果有那就更得劲了✅。

经过我一番搜索，发现了这个网站：model-viewer，收集了很多英雄联盟的人物模型，模型里面还有各种动画，还给下载。老表，这个需求稳了50%了！

接下来有几种选择：

• 将模型动画转成动画帧，搞成雪碧图，较为麻烦，且动画不支持切换。


• 直接加载模型，将模型放在进度条上，较为简单，支持切换不同动画，而且可以自由过渡。就是模型文件有点大，初始化加载可能耗时较长。但是后续缓存一下就好了。

聪明的我肯定先选第二个方案呀，你糊弄我啊，我糊弄你。

3、实现

web中加载模型可以使用谷歌基于threejs封装的 model-viewer, 使用现代的 web component 技术。简单易用。

先初始化一个vue工程

 npm create vue@latest

然后将里面的初始化的组件和app.vue里面的内容都删除。

安装model-viewer依赖：

npm i three // 前置依赖

npm i @google/model-viewer

修改vite.config.js，将model-viewer视为自定义元素，不进行编译

import { fileURLToPath, URL } from 'node:url'

​

import { defineConfig } from 'vite'

import vue from '@vitejs/plugin-vue'

​

// https://vitejs.dev/config/

export default defineConfig({

  plugins: [

    vue({

      template: {

        // 添加以下内容

        compilerOptions: {

          isCustomElement: (tag) => ['model-viewer'].includes(tag)

        }

      }

    })

  ],

  resolve: {

    alias: {

      '@': fileURLToPath(new URL('./src', import.meta.url))

    }

  },

  assetsInclude: ['./src/assets/heros/*.glb']

})

​

新建 src/components/LolProgress.vue

<template>

  <div class="progress-container">

    <model-viewer

      :src="hero.src"

      disable-zoom

      shadow-intensity="1"

      :camera-orbit="hero.cameraOrbit"

      class="model-viewer"

      :style="heroPosition"

      :animation-name="animationName"

      :camera-target="hero.cameraTarget"

      autoplay

      ref="modelViewer"

    ></model-viewer>

    <div

      class="progress-bar"

      :style="{ height: strokeWidth + 'px', borderRadius: strokeWidth / 2 + 'px' }"

    >

      <div class="progress-percent" :style="currentPercentStyle"></div>

    </div>

  </div>

</template>

​

<script setup lang="ts">

import { computed, onMounted, ref, watch, type PropType } from 'vue'

/** 类型 */

interface Hero {

  src: string

  cameraOrbit: string

  progressAnimation: string

  finishAnimation: string

  finishAnimationIn: string

  cameraTarget: string

  finishDelay: number

}

type HeroName = 'yasuo' | 'yi'

​

type Heros = {

  [key in HeroName]: Hero

}

const props = defineProps({

  hero: {

    type: String as PropType<HeroName>,

    default: 'yasuo'

  },

  percentage: {

    type: Number,

    default: 100

  },

  strokeWidth: {

    type: Number,

    default: 10

  },

  heroSize: {

    type: Number,

    default: 150

  }

})

​

const modelViewer = ref(null)

​

const heros: Heros = {

  yasuo: {

    src: '/src/components/yasuo.glb',

    cameraOrbit: '-90deg 90deg',

    progressAnimation: 'Run2',

    finishAnimationIn: 'yasuo_skin02_dance_in',

    finishAnimation: 'yasuo_skin02_dance_loop',

    cameraTarget: 'auto auto 0m',

    finishDelay: 2000

  },

  yi: {

    src: '/src/components/yi.glb',

    cameraOrbit: '-90deg 90deg',

    progressAnimation: 'Run',

    finishAnimationIn: 'Dance',

    finishAnimation: 'Dance',

    cameraTarget: 'auto auto 0m',

    finishDelay: 500

  }

}

​

const heroPosition = computed(() => {

  const percentage = props.percentage > 100 ? 100 : props.percentage

  return {

    left: `calc(${percentage + '%'} - ${props.heroSize / 2}px)`,

    bottom: -props.heroSize / 10 + 'px',

    height: props.heroSize + 'px',

    width: props.heroSize + 'px'

  }

})

​

const currentPercentStyle = computed(() => {

  const percentage = props.percentage > 100 ? 100 : props.percentage

  return { borderRadius: `calc(${props.strokeWidth / 2}px - 1px)`, width: percentage + '%' }

})

​

const hero = computed(() => {

  return heros[props.hero]

})

​

const animationName = ref('')

​

watch(

  () => props.percentage,

  (percentage) => {

    if (percentage < 100) {

      animationName.value = hero.value.progressAnimation

    } else if (percentage === 100) {

      animationName.value = hero.value.finishAnimationIn

      setTimeout(() => {

        animationName.value = hero.value.finishAnimation

      }, hero.value.finishDelay)

    }

  }

)

onMounted(() => {

  setTimeout(() => {

    console.log(modelViewer.value.availableAnimations)

  }, 2000)

})

</script>

<style scoped>

.progress-container {

  position: relative;

  width: 100%;

}

.model-viewer {

  position: relative;

  background: transparent;

}

.progress-bar {

  border: 1px solid #fff;

  background-color: #666;

  width: 100%;

}

.progress-percent {

  background-color: aqua;

  height: 100%;

  transition: width 100ms ease;

}

</style>

组件非常简单，核心逻辑如下：

• 根据传入的英雄名称加载模型


• 指定每个英雄的加载中的动画，


• 加载100%,切换完成动作进入动画和完成动画即可。


• 额外的细节处理。
  
  

  最后修改 app.vue:

  
  

  <script setup lang="ts">
  
  import { ref } from 'vue'
  
  import LolProgress from './components/LolProgress.vue'
  
  const percentage = ref(0)
  
  setInterval(() => {
  
    percentage.value = percentage.value + 1
  
  }, 100)
  
  </script>
  
  ​
  
  <template>
  
    <main>
  
      <LolProgress
  
        :style="{ width: '200px' }"
  
        :percentage="percentage"
  
        :heroSize="200"
  
        hero="yasuo"
  
      />
  
    </main>
  
  </template>
  
  ​
  
  <style scoped></style>
  
  ​
  
  

  
  

这不就完成了吗，先拿给老板看看。

老板：换个女枪的看看。

我：好嘞。

老板：弄类不赖啊小伙，换个俄洛伊的看看。

4、总结

通过本次需求，了解到了 model-viewer组件。

老板招个UI妹子吧。

在线体验：github-pages

前言

做了7年前端我一直不知道瀑布流是什么（怪设计师不争气啊，哈哈哈），我一直以为就是个普通列表，几行css解决的那种。

当然瀑布流确实有css解决方案，但是这个方案对于分页列表来说完全不能用，第二页内容一出来位置都变了。

我看了一下掘金的一些文章，好长啊，觉得还是自己想一下怎么写吧。就自己实现了一遍。希望思路给大家一点帮助。

分析瀑布流

以小红书的瀑布流为例，相同宽度不同高度的卡片堆叠在一起形成瀑布流。

这里有两个难点：

• 卡片高度如何确定？


• 堆叠布局如何实现？

卡片的高度 = padding + imageHeight + textHeight....

不固定的内容包括：图片高度、标题行数

也就是说当我们解决了图片和标题的高度问题，那么瀑布流的第一个问题就解决了。（感觉已经写好代码了一样）

堆叠问题——因为css没有这样的布局方式，所以肯定得用js实现。最简单的解决方案就是对每一个盒子进行绝对定位。

这个问题就转换成计算现有盒子的定位问题。

从问题到代码

第一个问题——图片高度

无论是企业业务场景还是个人开发，通过后端返回图片的width、height都是合理且轻松的。

前端去获取图片信息，无疑让最重要的用户体验变得糟糕。前端获取图片信息并不困难，但是完全没有必要。

所以我直接考虑后端返回图片信息的情况。

const realImageHeight = imageWidth / imageHeight * cardContentWidth;  

图片高度轻松解决，无平台差异

第二个问题——文字高度

从小红书可以看出，标题有些两行有些一行，也有些三行。

如果你固定一行，这个问题完全可以跳过。

• 方案一：我们可以用字数和宽度来计算可能得行数
  
  优势：速度快，多平台复用
  
  劣势：不准确（标题包括英文中文）


• 方案二：我们可以先渲染出来再获取行数
  
  优势：准确
  
  劣势：相对而言慢，不同平台方法不同

准确是最重要的！选择方案二

其实方案二也有两种方案，一种是用canvas模拟，这样可以最大限度摆脱平台（h5、小程序）的限制，

然而我试验后，canvas还没找到准确的计算的方法（待后续更新）

第二种就是用div渲染一遍，获取行数或者高度。

创建一个带有指定样式的 div 元素

function createDiv(style: string): HTMLDivElement {  

    const div = document.createElement('div');  

    div.style.cssText = style;  

    document.body.appendChild(div);  

    return div;  

}  

计算文本数组在指定字体大小和容器宽度下的行数

/**  

* 计算文本数组在指定字体大小和容器宽度下的行数  

* @param texts - 要渲染的文本数组  

* @param fontSize - 字体大小（以像素为单位）  

* @param lineHeight - 字体高度（以像素为单位）  

* @param containerWidth - 容器宽度（以像素为单位）  

* @param maxLine - 最大行数（以像素为单位）  

* @returns 每个文本实际渲染时的行数数组  

*/  

export function calculateTextLines(  

    texts: string[],  

    fontSize: number,  

    lineHeight: number,  

    containerWidth: number,  

    maxLine?: number  

): number[] {  

// 创建一个带有指定样式的 div 元素  

    const div = createDiv(`font-size: ${fontSize}px; line-height: ${lineHeight}px; width: ${containerWidth}px; white-space: pre-wrap;`);  

    const results: number[] = [];  

    texts.forEach((text) => {  

        div.textContent = text;  

        // 获取 div 的高度，并根据字体大小计算行数  

        const divHeight = div.offsetHeight;  

        const lines = Math.ceil(divHeight / lineHeight);  

        maxLine && lines > maxLine ? results.push(maxLine) : results.push(lines);  

    });  

  

    // 清理 div  

    removeElement(div);  



    return results;  

}  

这个问题小程序如何解决放在文末

第三个问题——每个卡片的定位问题

解决了上面的问题，就解决了盒子高度的问题，这个问题完全就是相同宽度不同高度盒子的堆放问题了

问题的完整描述是这样的：

写一个ts函数实现将一堆小盒子，按一定规则顺序推入大盒子里

函数输入：小盒子高度列表

小盒子：不同小盒子高度不一致，宽度为stackWidth，彼此间隔gap

大盒子：高度无限制，宽度为width

堆放规则：优先放置高度低的位置，高度相同时优先放在左侧

返回结果：不同盒子的高度和位置信息

如果你有了这么清晰的描述，接下去的工作你只需要交给gpt来写你的函数

// 返回的盒子信息  

export interface Box {  

    x: number;  

    y: number;  

    height: number;  

}  

// 盒子堆叠的方法类  

export class BoxPacker {  

    // 返回的小盒子信息列表  

    private boxes: Box[] = [];  

    // 大盒子宽度  

    private width: number;  

    // 小盒子宽度  

    private stackWidth: number;  

    // 小盒子间隔  

    private gap: number;  



    constructor(width: number, stackWidth: number, gap: number) {  

    this.width = width;  

    this.stackWidth = stackWidth;  

    this.gap = gap;  

    this.boxes = [];  

}  

// 添加单个盒子  

public addBox(height: number): Box[] {  

    return this.addBoxes([height]);  

}  

// 添加多个盒子（一般用这个方法）  

public addBoxes(heights: number[], isReset?: boolean): Box[] {  

    isReset && (this.boxes = [])  

    console.log('this.boxes—————— ', JSON.stringify(this.boxes) )  



    for (const height of heights) {  

        const position = this.findBestPosition();  

        const newBox: Box = { x: position.x, y: position.y, height };  

        this.boxes.push(newBox);  

    }  

    return this.boxes;  

}  

// 查找定位函数  

private findBestPosition(): { x: number; y: number } {  

    let bestX = 0;  

    let bestY = Number.MAX_VALUE;  



    for (let x = 0; x <= this.width - this.stackWidth; x += this.stackWidth + this.gap) {  

        const currentY = this.getMaxHeightInColumn(x, this.stackWidth);  

        if (currentY < bestY || (currentY === bestY && x < bestX)) {  

            bestX = x;  

            bestY = currentY;  

        }  

    }  



    return { x: bestX, y: bestY };  

}  

  

private getMaxHeightInColumn(startX: number, width: number): number {  

    return this.boxes  

        .filter(box => box.x >= startX && box.x < startX + width)  

        .reduce((maxHeight, box) => Math.max(maxHeight, box.y + box.height + this.gap), 0);  

}  

}  

  

这样我们就实现了根据高度获取定位的功能了

来实现一波

核心的代码就是获取每个盒子的定位、宽高信息

// 实例  

const boxPacker = useMemo(() => {  

    return new BoxPacker(width, stackWidth, gap)  

}, []);  

  

const getCurrentPosition = (currentData: DataItem[], reset?: boolean) => {  

    // 获取标题文本行数列表  

    const textLines = calculateTextLines(currentData.map(item => item.title),card.fontSize,card.lineHeight, cardContentWidth)  

    // 获取图片高度列表  

    const imageHeight = currentData.map(item => (item.imageHeight / item.imageWidth * cardContentWidth))  

    // 获取小盒子高度列表  

    const cardHeights = imageHeight.map((h, index) => (  

    h + textLines[index] * card.lineHeight + card.padding * 2 + (card?.otherHeight || 0)  

    )  

    );  

    // 获取盒子定位信息  

    const boxes = boxPacker.addBoxes(  

        cardHeights,  

        reset  

    )  

    // 返回盒子列表信息  

    return boxes.map((box, index) => ({  

        ...box,  

        title: currentData[index]?.title,  

        url: currentData[index]?.url,  

        imageHeight: imageHeight[index],  

    }))  

}  

set获取到的盒子信息

const [boxPositions, setBoxPositions] = useState<(Box & Pick<DataItem, 'url' | 'title' | 'imageHeight'>)[]>([]);  

useEffect(() => {  

    // 首次和刷新  

    if (page === 1) {  

        setBoxPositions(getCurrentPosition(data, true))  

    } else {  

    // 加载更多  

        setBoxPositions(getCurrentPosition(data.slice((page - 1) * pageSize, page * pageSize)))  

    }  

}, [])  

效果如下

小程序获取文本高度

从上面的分析可以看出来只有文本高度实现是不同的，如果canvas方案实验成功，说不定还能做到大一统。

目前没成功大家就先看看我的目前方案：先实际渲染文字然后读取信息，然后获取实际高度

import React, {useEffect, useMemo, useState} from 'react'  

import { View } from '@tarojs/components'  

import Taro from "@tarojs/taro";  

import './index.less'  

import {BoxPacker} from "./flow";  

  

const data = [  

    'vwyi这是一个标题，这是一个标题，这是一个标题，这是一个标题',  

    '这是一个标题',  

    '这是一个标题,这是一个标题,这是一个标题,这是一个标题',  

    '这是一个标题',  

    '这是一个标题,这是一个标题,这是一个标题,一个标题',  

    '这是一个标题,这是一个标题,这是一个标题,这题',  

    '这是一个标题,这是一个标题,这是一',  

    '这是一个标题,这是一个标题,这是一',  

];  

  

function Index() {  

const boxPacker = useMemo(() => new BoxPacker(320, 100, 5), []);  

  

const [boxPositions, setBoxPositions] = useState<any[]>([])  

function getTextHeights() {  

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

    Taro.createSelectorQuery()  

        .selectAll('#textContainer .text-item')  

        .boundingClientRect()  

        .exec(res => {  

            if (res && res[0]) {  

                const heights = res[0].map(item => item.height);  

                resolve(heights);  

            } else {  

                reject('No buttons found');  

            }  

        });  

    });  

}  

useEffect(() => {  

    getTextHeights().then(h => {  

        setBoxPositions(boxPacker.addBoxes(h))  

    })  

}, [])  

return (  

<View className="flow-container">  

<View id="textContainer">  

{  

data.map((item, index) => (<View key={index} className="text-item">{item}</View>))  

}  

</View>  

<View className="text-box-container">  

{boxPositions.map((position, index) => (  

<View  

key={index}  

className="text-box"  

style={{  

left: `${position.x}px`,  

top: `${position.y}px`,  

height: `${position.height}px`,  

width: '100px', // 假设盒子的宽度固定为100px  

}}  

>  

{`${data[index]}`}  

</View>  

))}  

  

</View>  

  

</View>  

)  

}  

  

export default Index  

  

项目react源码地址

点赞 + 关注 + 收藏 = 学会了

本文简介

最近字节在推Coze，你可以在这个平台制作知识库、制作工作流，生成一个具有特定领域知识的智能体。

那么，有没有可能在本地也部署一套这个东西呢？这样敏感数据就不会泄露了，断网的时候也能使用AI。

刚好最近 Llama 3.1 发布了，本文就以 Llama 3.1 作为基础模型，配合 Dify 在本地搭建一套“Coze”。

跟着本文一步步操作，保证能行！

Dify是什么？

Dify 官网(difyai.com/) 的自我介绍：Dify 是开源的 LLM 应用开发平台。提供从 Agent 构建到 AI workflow 编排、RAG 检索、模型管理等能力，轻松构建和运营生成式 AI 原生应用。比 LangChain 更易用。

动手搭建

在本地搭建这个平台很简单，其实 Dify文档(docs.dify.ai/v/zh-hans) 里都写得明明白白了，而且还有中文文档。

具体来说需要做以下几步：

接下来一步步操作。

安装 Ollama

简单来说 Ollama 是运行大语言模型的环境，这是 Ollama 的官网地址 （ollama.com/ ），打开它，点击 Download 按钮下载 Ollama 客户端，然后傻瓜式安装即可(一直点“下一步”)。

安装完成后就能看到一个羊驼的图标，点击运行它即可。

下载大模型

安装完 Ollama 后，我们到 Ollama 官网的模型页面(ollama.com/library)挑选一下模型。

这里面有很多开源模型，比如阿里的千问2，搜索 qwen2 就能找到它。

本文使用 Llama 3.1 ，这是前两天才发布的模型，纸面参数贼强。

打开 Llama 3.1 模型的地址(ollama.com/library/lla…)，根据你需求选择合适的版本，我选的是 8b 版。

选好版本后，复制上图右侧红框的命令，到你电脑的终端中运行。

如果你还没下载过这个模型它就会自动下载，如果已经下载过它就会运行这个模型。

运行后，你就可以在终端和大模型对话了。

当然，我们不会这么原始的在终端和大模型对话，我们可是要搞工作流的！

安装 Docker

前面的基础步骤都搞掂了，接下来就要开始为运行 Dify 做准备了。

先安装一下 Docker ，打开 Docker 官网(http://www.docker.com/)，根据你系统下载对应的安装包，然后还是傻瓜式安装即可。

克隆 Dify 源代码至本地

要使用 Dify ，首先要将它拉到你电脑里。

git clone https://github.com/langgenius/dify.git

在你电脑里找个位置（目录），用 git 将 Dify 克隆下来，用上面这条命令克隆就可以了。

启动 Dify

进入 Dify 源代码的 docker 目录，执行一键启动命令：

cd dify/docker

cp .env.example .env

docker compose up -d

启动完成后，你的 docker 里就会看到这个

此时你在浏览器输入 http://localhost 就能看到这个界面。

首次打开 Dify 需要你设置一下管理员的账号。

然后用管理员账号登录，可以看到下面这个页面。

点击“创建空白应用”就可以创建聊天助手、文本生成应用、Agent、工作流。

我们点击"工作流"就能看到类似Coze的工作流编辑界面了。

配置模型

在配置工作流之前，我们需要给 Dify 配置大语言模型。

点击页面右上角的管理员头像，然后选择“设置”。

选择“模型供应商”，然后点击“Ollama”的卡片添加模型。

在添加 Ollama 模型时，弹窗的左下角有一个“如何继承 Ollama”的按钮，点击它会跳转到 Dify 官方文档教你怎么配置，但这里可能会有个小坑。

前面我们已经使用 Ollama 把 Llama 3.1 运行起来了，在浏览器打开 `http://localhost:11434 看到这个界面证明模型运行成功。

此时在“添加 Ollama”将资料填写好，“基础 URL”里输入 http://localhost:11434 即可。

如果你是 Mac 电脑，填入以上资料有可能会报这个错：

An error occurred during credentials validation: HTTPConnectionPool(host='localhost', port=11434): Max retries exceeded with url: /api/chat (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0xffff5e310af0>: Failed to establish a new connection: [Errno 111] Connection refused'))

此时你需要在“基础 URL”里填入 http://host.docker.internal:11434。

遇到问题可以看 Dify 官方文档的 FAQ。

添加完成后你就可以在模型列表里看到它了。

除了接入 Ollama 外，Dify 还支持接入 OpenAI 等闭源模型，但需要你去 OpenAI 那边买个服务。

以上就是本文的全部内容啦，如果本文对你有帮助的话也请你分享给你的朋友～

点赞 + 关注 + 收藏 = 学会了

相信不少前端从业者一听uniapp支持开发鸿蒙Next后非常振奋。猫林老师作为7年前端er也是非常激动，第一时间体验了下。在这里也给大家分享一下我的看法

uniapp开发鸿蒙优势

uniapp开发鸿蒙缺点

• 这真的是可以大吐特吐的地方了，uniapp目前支持鸿蒙的方案是web渲染方案，也就是说相当于利用鸿蒙内部的webview显示一个网页


• 那这有什么不好呢？
  
  
  
  
  1. 首先是渲染性能达不到原生、其次是逻辑代码是JS实现，而JS引擎慢，这就导致启动速度和运行速度弱于原生
  
  
  2. JS与原生UI层或者原生API通信可能会卡顿
  
  
  
  


• 其次是目前仅支持vue3，对于还在守着vue2的古早前端也不友好


• 以上结论来自uniapp官网说明，如下图

• 因此猫林老师不认为目前的uniapp适合鸿蒙开发，所以如果有志于抢占鸿蒙风口的同学，可以坚定信心了，还是得好好学习鸿蒙原生开发。

uniapp未来会好吗？

• 上述缺点其实DCloud官方（uniapp所属）也意识到了，所以一直在打造新一代的uniapp，也即uni-app x


• 这套新平台追求解决所有跨平台开发框架性能无法媲美原生的痛点，通过不同平台编译成不同语言来实现：在iOS平台编译为swift、在Android平台编译为kotlin、在Web和小程序平台编译为js、在鸿蒙next平台上编译为ArkTS。就相当于你用vue的语法写了原生的代码。


• 因此，未来的uniapp还是非常值得期待的！


• 但现阶段，虽然uni-app x也已经对外发布，但是对于鸿蒙的支持还在不断的完善。并且鸿蒙自身也在不断的升级迭代，所以现阶段的uni-app x暂时还是无法展现完整的鸿蒙开发之美。期望未来能越来越好，为鸿蒙生态提供强有效的生产力。

总结

uniapp支持鸿蒙是一个好消息，未来也值得期待。但是现阶段用来作为找鸿蒙开发岗位的工作还是不太合适。

大家好，我是 Gopal。好久不见，甚是想念！

本篇文章记录一下今年我做的一个比较大胆的决定——做近视手术。

首先声明一下，本篇文章不是广告，纯分享个人经历，看完这篇文章，至于要不要做视力矫正？怎么做？个人可以根据需要自行决定哈。

我为什么要摘镜

先说一下，我的情况。我是初中毕业后开始慢慢近视的，至今的话，也有十来年了，眼镜都配了好多副。有近视的同学应该都知道，近视确确实实带给我们很多的烦恼，我举几个例子：

基于以上的种种，摘镜意愿，我个人是比较强烈的。当我听说现在有手术可以进行视力矫正时候，是非常兴奋的。我之后做了相关的调查，我们来看一下视力矫正有哪些方案吧。

视力矫正有哪些方案

这里我会介绍得比较粗糙一些，毕竟我不是专业的，知识都是我从网络中总结得来。

近视原因：我们大部分人的近视都是轴性近视，是由于眼球的前后长度（轴长）延长造成的，可以看以下的图片。在正常眼中，平行光线入眼后在视网膜上形成焦点。而在近视眼中，焦点位置落在视网膜之前，近视眼想看清，就得调整屈光度，使其聚焦在视网膜上。

眼镜通过镜片调节屈光度，而近视手术的大致有两种方式进行：

• 第一种，通过角膜手术改变角膜的形态和屈光力，使物象成像到视网膜上。


• 第二种，更换晶体或向眼内植入补偿晶体，从而达到类似的效果，这种类似于带隐形眼镜。

其中有一个特点就是晶体是有可逆性，激光手术的话，是不可逆的。以上两种并没有说哪种是最优解，需要通过医院检查才能决定。一般来说，角膜屈光手术建议近视度数小于 1000 度，散光小于 600 度。如果因为度数过高、或角膜太薄不能做角膜屈光手术，可以考虑做晶体植入手术。

现在主流的手术方案有以下四种（前面三种都属于角膜手术），具体的这里不展开了，大家有想法可以自行搜索哈。

• Smart全激光


• 半飞秒


• 全飞秒Smile


• ICL晶体植入术

而我通过检查之后，选择了全飞秒Smile。主要是我度数还好，角膜厚度也足够。

手术前中后

首先约了一家上市的机构做检查，看得出还是比较慎重，各个方面评估能不能做，以及有哪些方案，最后会有专门的人给我讲解。

做完检查之后，我当时就约了隔周去做，因为手术前几天是需要滴眼药水，而且不能佩戴隐形眼镜等。

手术当天，做术前检查，交代注意事项/术后用药、签署同意书等。说实话，我还是比较紧张的，毕竟把眼睛这么重要的部位交给医生。

然后就是手术了，真正的手术时间也就几分钟，当躺在手术室中，一开始我以为医生还在给我做前置检查，没想到几分钟后医生告诉我已经结束了，可以回家了。手术过程滴麻药，基本不会痛的。整个激光过程，眼睛是会有开睑器撑开固定，手术过程眼睛是同时睁开/闭上的。手术过程中，需要在打激光的过程中配合，眼睛保持不动不眨，听好医生指令。

手术后，我和我对象就坐地铁回去了，回家的路上，我一直戴着墨镜，随着麻药的失效，会有一种较强的异物感。虽然我知道这是一个正常现象（医生提前已告知，手术后将会在4-6小时内会出现流泪、畏光、白雾感、异物感、酸胀感等刺激症状，其轻重因人而异），但是当时真的挺怕的，毕竟可不是小事。（所以最好手术当天最好还是有人一起去）。

当天下午，我就感觉好很多了。我做的事全飞秒，周六做的手术，周一的时候，我就可以正常上下班了，基本不会影响工作。唯一我感知到的一点点影响就是切换屏幕的时候，聚焦会需要一点点时间，很短，医生说是正常现象。不过中间需要注意用眼，然后注意按照医嘱滴眼药水等。这里我贴几个术后的注意事项，当然你应该根据你的主治医生来：

在写本文的时候，已经有两个多月了，感觉日常生活没啥影响。在一个月复诊的时候，我的视力一边是 1.2，一边是 1.5。如果说有啥「副作用」的话，有两点。一个是晚上的视力（在光线比较差的地方）会稍微有点差，另外一个看一些光源（比如路灯），会有一点炫光。不过这些术前医生有给我说过，我是有做好心理准备的。

整体而言，目前为止，我对这次的近视手术还是很满意的。

手术价格以及副作用

这个我相信不少人比较关注，我做的全飞秒，全部下来大概 1.8w 左右（公司跟这家机构有合作，跟我说是打了折扣，我了解了一下，在深圳，这个价格其实差不多）。激光和半分秒会稍微便宜一些。晶体植入是最贵的（大概 3w 多）。具体的还需要根据不同的城市和机构看。据说虽然近视手术简单，但是它那个机器是需要给专利费用的，用一次给一次专利费用。整体上讲，这个还是可以接受的。另外，近视手术不能报医保。

比如价格，我觉得大家最关心的问题是副作用，或者说风险系数。任何手术都是有风险的，包括近视手术。网络上会有人说：

• 近视手术这么好，为什么医生也还带眼镜？


• 近视手术这么好，为什么马化腾还带眼镜？


• ...

首先，先不否认大家的疑虑，毕竟眼睛这么重要的东西，要在上面动手术，想想都怕。但是，我们也需要辩证的看待这些问题。

• 近视手术是需要满足一定条件的，不满足的话，医院是不敢给你做的。


• 近视手术是不会导致你瞎的，从原理上来说，近视手术是眼睛前面部分的手术，不涉及眼部深层组织，比如晶状体、视网膜等，更加不可能致盲。


• 近视手术存在发生并发症的可能性，可能性大小而已。（别人没有，并不代表自己没有）比如眼干等。虽然现在手术已经很成熟，但是在你决定要做之前，一定要先了解清楚，看你能不能承担这个风险。


• 近视手术只是当前帮你调整好你的视力，假如你不注意用眼的话，是存在再次近视的风险的。所以一般建议成年之后，度数稳定之后再做这个手术。


• ...

最后再强调一遍，近视手术是一种改善型的手术，不做其实本质上对于自身身体健康没有影响，如果摘镜意愿强烈的同学可以尝试去了解一下。

写在最后

目前为止，我感受到更多的是摘镜之后给我生活带来的便利，基本算是满足了我摘镜的预期！

我之前一直在想，假如哪天我落在一座荒岛上，估计是活不下去的。因为假如一旦我眼镜坏了，那么我就「看不清」这个世界了。

不过现在医学科技的进步解决了我的这个问题。

面试官：看你简历上做过图片或文件批量下载，那么假如我一次性下载几十个，如何去控制并发请求的？

让我想想，额~， 选中ID，循环请求？，八嘎！肯定不是那么沙雕的做法，这样做服务器直接崩溃啦！突然灵光一现，请求池！！！

我：利用Promise模拟任务队列，从而实现请求池效果。

面试官：大佬！

废话不多说，正文开始：

众所周知，浏览器发起的请求最大并发数量一般都是6~8个，这是因为浏览器会限制同一域名下的并发请求数量，以避免对服务器造成过大的压力。

首先让我们来模拟大量请求的场景

const ids = new Array(100).fill('')



console.time()

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

  console.log(i)

}

console.timeEnd()

一次性并发上百个请求，要是配置低一点，又或者带宽不够的服务器，直接宕机都有可能，所以我们前端这边是需要控制的并发数量去为服务器排忧解难。

什么是队列？

先进先出就是队列，push一个的同时就会有一个被shift。我们看下面的动图可能就会更加的理解：

我们接下来的操作就是要模拟上图的队列行为。

定义请求池主函数函数

export const handQueue = (  

  reqs // 请求数量

) => {}

接受一个参数reqs，它是一个数组，包含需要发送的请求。函数的主要目的是对这些请求进行队列管理，确保并发请求的数量不会超过设定的上限。

定义dequeue函数

const dequeue = () => {  

  while (current < concurrency && queue.length) {  

    current++;  

    const requestPromiseFactory = queue.shift() // 出列  

    requestPromiseFactory()  

      .then(() => { // 成功的请求逻辑  

      })  

      .catch(error => { // 失败  

        console.log(error)  

      })  

      .finally(() => {  

        current--  

        dequeue()  

      });  

  }  

}

这个函数用于从请求池中取出请求并发送。它在一个循环中运行，直到当前并发请求数current达到最大并发数concurrency或请求池queue为空。对于每个出队的请求，它首先增加current的值，然后调用请求函数requestPromiseFactory来发送请求。当请求完成（无论成功还是失败）后，它会减少current的值并再次调用dequeue，以便处理下一个请求。

定义返回请求入队函数

return (requestPromiseFactory) => {  

  queue.push(requestPromiseFactory) // 入队  

  dequeue()  

}

函数返回一个函数，这个函数接受一个参数requestPromiseFactory，表示一个返回Promise的请求工厂函数。这个返回的函数将请求工厂函数加入请求池queue，并调用dequeue来尝试发送新的请求，当然也可以自定义axios，利用Promise.all统一处理返回后的结果。

实验

const enqueue = requestQueue(6) // 设置最大并发数

for (let i = 0; i < reqs.length; i++) {  // 请求

  enqueue(() => axios.get('/api/test' + i))  

}

我们可以看到如上图所示,请求数确实被控制了，只有有请求响应成功的同时才会有新的请求进来，极大的降低里服务器的压力，后端的同学都只能喊6。

整合代码

import axios from 'axios'



export const handQueue = (

  reqs // 请求总数

) => {

  reqs = reqs || []





  const requestQueue = (concurrency) => {

    concurrency = concurrency || 6 // 最大并发数

    const queue = [] // 请求池

    let current = 0



    const dequeue = () => {

      while (current < concurrency && queue.length) {

        current++;

        const requestPromiseFactory = queue.shift() // 出列

        requestPromiseFactory()

          .then(() => { // 成功的请求逻辑

          })

          .catch(error => { // 失败

            console.log(error)

          })

          .finally(() => {

            current--

            dequeue()

          });

      }



    }



    return (requestPromiseFactory) => {

      queue.push(requestPromiseFactory) // 入队

      dequeue()

    }



  }



  const enqueue = requestQueue(6)



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



    enqueue(() => axios.get('/api/test' + i))

  }

}

实战文章

之前写过一篇关于web-worker大文件切片的案例文章，就是利用了此特性感兴趣的小伙伴可以看看web-worker的基本用法并进行大文件切片上传（附带简易node后端）

一、前言

   相信很多人有过接手别人的系统，也有将自己负责的系统交接给别人的经历。既有交接出去不用在费力治理维护技术债务的喜悦，也有接手对方系统面对一系列维护问题的愁容满面。

   但是被人嫌弃的系统曾经也是「创建人」心中的白月光啊，是什么导致了「白月光」变成了「牛夫人」呢？是996，工期倒排、先上再优化，还是随时变动的需求？

   让我们来复盘系统是怎么一步一步腐化的，让我们丢失了最初的兴趣，同时总结一些经验教训以及破局之策。

二、白月光到牛夫人的经历

一般当我们设计一个系统时，总是会抱着要把该项目打造为「干净整洁」的项目的想法，

但是随着时间的推移，最后总是不可避免的变成了这样：

2.1、从0到1

   我们发现大多数人对于创建新项目总是会抱有极大的激情兴趣，会充分的考虑架构设计。但是对于接手的项目就会缺乏耐心。

   这种心理在《人月神话》一书中被说为编程职业的乐趣：

“首先，这种快乐是一种创建事物的纯粹快乐。如同小孩在玩泥巴时 感到快乐一样，成年人喜欢创建事物，特别是自己进行设计 。我想这种 快乐是上帝创造世界的折射，一种呈现在每片独特的、崭新的树叶和雪 花上的喜悦。”

“第四，这种快乐是持续学习的快乐，它来自于这项工作的非重复特性。人们所面临的问题总有这样那样的不同，因而解决问题的人可以从 中学习新的事物，有时是实践上的，有时是理论上的，或者兼而有之。”



正是由于这样的心理，人们在面对新系统时，可以实践自身所学，主动思考如何避开曾经遇到的坑。满足了内心深处的对于创造渴望。
   当一个项目是从0到1开始设计的，并且前期是由少数「高手」成员主导开发的话，一般不会有债务体现。当然明面上没有债务，不代表没有埋下债务的种子。

2.2、抢占市场、快速迭代

   系统投入市场得到验证后，如果顺利，短期会收获大量用户。伴随着用户指数增长的同时，各种产品需求也会随着而来。一般在这个阶段将会是「工期倒排、先上再优化，需求随时变动」的高发期。

   同时由于需求的爆发，为了提高团队的交付率，在这个阶段会引入大量的“新人”。随着带来的就是新老思想的碰撞，新的同学不一定认同之前的架构设计。

   在这个阶段，如果团队存在主心骨，可以“游说”多方势力，平衡技术产品、新老开发之间的矛盾，那么在这个阶段引入的债务将会还好。但是如果团队缺乏这样的角色，就会导致公说公有理婆说婆有理，最后的结果就是架构会朝着多个方向发展，一个项目里充斥着多种不同思路的设计。有些甚至是矛盾的。如果还有【又不是不能用】的想法出现，那将是灭顶之灾。



但是在这个阶段对于参与者又是幸福的，一份【有市场、有用户、有技术、有价值】的项目，无论是对未来的晋升还是跳槽都是极大的谈资。

2.3、维护治理

   褪去了前期“曾经沧海难为水，除却巫山不是云”的热恋后，剩下的就是生活的柴米油盐。系统的最终结局也是“维护治理”。

   在这个阶段，需求的数量将大大减少，但是由于前期的“快速建设”，一个小小的需求，我们可能需要耗费数周的时间去迭代。而且系统越来越复杂，迭代越来越困难。
   
同时每天需要花费大量的时间处理客诉、定位bug，精力被完全分散。系统的设计和技术慢慢的变得僵化。并且由于用户量巨大，每次改动都要承担很大的线上风险。这样的情况对于程序员的精力、体力都是一场内耗，并且如果领导的重心也不在此项目时，更会加重这种内耗。于是该系统就会显得“人老色衰”，曾经的「白月光」也就变成了「牛夫人」。

三、牛夫人不好吗？

3.1、缺乏成就感

《人月神话》中关于程序员职业的苦恼曾说过以下几点：

随着业务趋于稳定，能够发挥创造性的地方越来越少，剩下的更多是沉闷、枯燥的维护工作。并且公司的资源会更聚焦在新业务、新方向，旧系统获得的关注更少，自然而然就缺乏成就感。也就形成了【只见新人笑，不见旧人哭】

3.2、旧系统复杂、难以维护

《A Philosophy of Software Design》一书中对复杂性进行了如下定义：“Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.”，即任何使得软件难于理解和修改的因素都是复杂性。

作者John 教授又分别从三个角度进行了解释复杂性的来源：

3.2.1、变更放大

   复杂性的第一个征兆是，看似简单的变更需要在许多不同地方进行代码修改。对于复杂的系统来说，如果代码没有聚敛，那么一次小小的需求可能会导致多处修改。同时为了保证不出故障，需要对涉及的修改点、功能点进行完整的覆盖测试。这种隐藏在背后的工作量是巨大的。

3.2.2、认知负荷

   复杂性的第二个症状是认知负荷，这是指开发人员需要多少知识才能完成一项任务。当一个系统经过多年的迭代开发，其复杂度将是指数级别的。并且会充斥这很多只有“当事人”才能理解的“离谱”功能。这就对维护者提出了极高的要求，需要掌握很多“冰山下”的知识才能做到手到擒来。而这对维护者的耐心、能力又是一次挑战。

3.2.3、未知的未知

   未知的未知是指必须修改哪些代码才能完成任务，或者说开发人员必须获得哪些信息才能成功地执行任务。这一项也是John Ousterhout教授认为复杂性中最糟糕的一个表现形式。
     这句话看起来比较抽象，如果映射到我们日常的工作中就是“我也不知道为啥这么改就好了”、“在我这是好的呀”、“刚刚还能运行啊，不知道为啥现在突然不行了”。

   这种情况就是我们不知道改动的这行代码是否能让程序正常运转，也不知道这行代码的改动是否又会引发新的问题。这时候我们发现，那些“上帝类”真的就只有上帝能拯救了。

   我曾经维护一个老系统，源码是通过文件相互传递的，没有仓库，里面的框架是自己撸的轮子，没有任何说明文档。服务部署是先在本地编译成二进制文件，然后在上传到服务器启动。每次改动上线都是就是一次生死劫，幸好没过多久，这个系统就被放弃了。

四、为何变成了牛夫人

4.1、伪敏捷

   “敏捷”已经成为了国内公司的银弹了。
   需求不做市场分析、不考虑用户体验、不做设计分析、不考虑前因后果，美其名曰“敏捷”。
   工期倒排、先上再说、明天能不能上、这个问题上了再优化，美其名曰“敏捷”。

   我曾经参与过一个项目，最开始是给了三个月的时间完成产品规划+开发，但是项目立项后领导层迟迟无法达成统一，一直持续进行了两个月的讨论后，终于确定了产品模型，进入开发。到这里留给开发的时间还剩一个月，咬咬牙也能搞定。但是开发真正进场，上报了需要开发的周期后，上面觉得太慢了，要求3周搞定，过了一天还是觉得太慢，要求2周，最后变成了要求4天搞定。遇到这种情况能怎么办，只能加人，只能怎么快怎么来。

   之前阿里程序员也开玩笑式的说出了类似的场景：“2月13号上午省领导问逍遥子全省的健康码今天上线行不行，逍遥子说可以。等消息传达到产研团队的时候已经是中午了，然后团队在下午写了第一行代码。”

4.2、人的认知局限

   《人月神话》一书中提到了一种组建团队的方式「外科手术团队」：“十个人，其中七个专业人士在解决问题，而系统是一个人或者最多两个人思考的产物，因此客观上达到了概念的一致性。”
   也就是团队只需要一个或者两个掌舵人，负责规划团队的方向和系统架构，其余人配合他完成任务。目前我所待过的团队也基本是按照这个模式组成的，领导会负责重要事情的决策和团队分歧时的拍板，其余人则相互配合完成目标任务。但是这样的模式也导致了一个问题：掌舵人的认知上限就决定了团队的上限，而这种认知上限天然就会导致系统架构设计存在局限性，而这种局限性又会随着“伪敏捷”放大。

4.3、人员流动

   经历过这种离职交接、活水交接的打工人应该深有体会，很多项目一旦步入这个阶段，大多数负责人就会开始放飞自我，怎么快怎么来，只想快点结束这段工作，快速奔赴下一段旅程。
   从人性的角度是很难评价这种情况的，毕竟打工人和老板天然就不是一个战线的，甚至可能是对立面的。而我们大多数人都不可能是圣人，从自身角度从发这种行为是无可厚非的。

五、如何保持白月光

   这里想首先抛个结论，系统变腐化是不可避免的。就类似人一样，随着时间的流逝，也会从以前一个连续熬夜打游戏看小说第二天依旧生龙活虎的青年变为一个在工位坐半小时都腰酸背痛，快走几步都喘的中年人。而这都来源于生活的压力、家庭的压力、工作的压力。同样的，面对业务的压力、抢占市场的压力、盈利的压力，系统也不可避免会变成“中年人”。
   就像人一样会使用护肤品、健身等手段延缓自己的衰老一样，我们也可以使用一些手段延缓系统“衰老”。
   在网上，已经有无数的文章教怎么避免代码腐化了，例如“DDD领域驱动设计”、“业务建模”、“重构”等等。
   今天我想从别的角度聊聊怎么延缓代码腐化。

5.1、避免通用

   软件领域有个特点，那就是复用。程序员们总是在思考怎么样写一段到处通用的代码，以不变应万变。特别是当国内提出中台战略后，这种情况就如脱缰的野马一般，不可阻挡。要是你做的业务、架构不带上xx中台，赋能xx，你都觉得你低人一等。
   但是其实我们大部分人做的都是业务系统，本身就是面向某块特定市场的、特定用户的。这就天然决定了其局限性。
   很多时候你会发现你用了100%的力气，设计了一个80%你认为有用的通用中台，最后只有20%产生了作用，剩下60%要么再也没有动过，要么就是被后来参与者喷的体无完肤。
   当然这里也不说，设计时就按照当前产品提出的需求设计就行，一点扩展的余地都不留，而是在「通用」与「业务需求」之间取一个平衡。而这种平衡就取决于经验了。如果你没有这方面经验，那你就去找产品要「抄袭」的是哪个产品，看看他们有哪些功能，可以预留这些功能的设计点。

5.2、Clean Code

说实话，国内的业务系统80%都没有到需要谈论架构设计的地步。能够做到以下几点已经赢麻了：

5.3、学会拒绝

   自从国内开始掀起敏捷开发的浪潮后，在项目管理方面就出现了一个莫名其妙的指标：每次迭代的需求数都有会有一个数值，而且还不能比上一次迭代的少。
   这种情况出现的原因是需求提出者无法确定这个需求可以带来多大的收益，这个收益是否满足老板的要求。那么他只能一股脑上一堆，这样即使最后效果不及预期，也可以怪罪于用户不买账。不是他不努力。
   在这种时候，就需要开发学会识别哪些是真需求，哪些是伪需求，对于伪需求要学会说不。当然说不，不是让你上来就是开喷，而是你可以提出更加合理的理由，甚至你可以提出其他需求代替伪需求。这一般需要你对这块业务有非常深入的研究，同时对系统有上帝视角。
   基本上在每个公司的迭代周期都是有时间要求的，比如我们就是两周一迭代，如果需求是你可控的，那么你就有更多的时间和心思在维护系统上，延缓他的衰老。

前两天在洋哥、竹子姐以及渡心总等大佬的带领下，第一次体验了穷爸爸富爸爸的作者研发的现金流游戏，收获颇丰！

游戏规则说明

心灵创富 现金流游戏分为三步：

一局游戏，时间两个小时；总结分享时刻；以及，最最重要的结合自己的生活，复盘自己关键时间点的选择，是否是符合财务自由的决策。

首先，说一下明面上的游戏规则：每个人都选择一张身份卡，这张身份卡决定了你的工资，还有每个月的现金流。你的身份可能是小学老师、飞机驾驶员、医生等等，他们月工资和现金流（每月结余）各不一样。

老鼠圈，所有玩家没实现财务自由之前都在老鼠圈。

游戏过程中，通过投掷骰子，可以有五种操作：

整个游戏的目标分为两个阶段：第一个阶段，突破老鼠圈，实现财务自由；第二个阶段，实现梦想。

怎么实现财务自由？股票、房产等带来的非工作收入超过你每个月的支出，就算破圈了，实现了财务自由，游戏进入了下一个阶段。

第一次玩游戏，没有人完成第二阶段，就不说了。

二、游戏

带领银行家：竹子

玩家：海子、木川、天雨、Feli、YY、伍六七

身份：小学老师

月工资：3300 $

月支出：2190 $

月现金流：1110 $

一开始选择身份的时候，虽然想选一个工资高的，但是也没有那么强烈，只是不想选工程师了，毕竟现实中是程序员，游戏中想换个身份活一回。所以，也就比较随意选择了工资偏低的小学教师。

整场游戏，我的运气非常不好。本来月现金流就不高，结果第二轮就生了个娃，后面又陆续抽中了额外支出，让本就没钱的我雪上加霜。

唯一称得上的是机会的就是：可以以 5000 $ 购买 10 亩荒地。但是当时没有考虑到可以向银行带款，也没有考虑到可以向其他玩家借款，最终没有购买。

没有考虑到向外部借钱的一部分原因是第一次玩这个游戏，不知道（忘记了）这个规则，另一个原因也是自己平时生活中也是这样一个人，除非迫不得已不向他人借钱。

第一次玩这个游戏，本着要恪守：10% - 20% 的钱投资高风险的产品（如股票），50% 的钱投资低风险的产品（当前最低价的股票、高收益的房产等）。

所以，我也做了两笔投资： 1000 $ 让木川代持的基金， 500 $ 让海子代持的股票。这让我在运气不好的一生中有一定的概率能破圈，虽然最后这两笔投资没有兑现，但是这两笔投资本身，我认为是没有问题的。

另外，太守规则。银行家一开始说的规则是不让给其他人提供决策建议，否则罚款。后来才知道，是可以向其他人提供付费资讯服务的，这种是不受惩罚的。

前两轮 FYY 想向我咨询决策建议，我直接就拒绝了。但是一个是给他人提供建议，可以给其他人好感，可以链接其他人。另外一个，就算有罚款，咨询的人也可以给予相应的补偿。这样就可以相互链接，相互成全。也应该思考，不破坏规则的情况下的有哪些选择。

整场游戏中，印象最深刻的一笔交易是：5000 $ 购买 10 亩荒地

我最终是没有购买，当时第一是看手里的现金，不满足购买要求。

第二是觉得这是一个可以搏一搏的机会，但是手里的现金不满足给自己制定的 10% -20% 投资高风险产品的 rule。

所以，问了在场的玩家，是否有需要这个机会的？拍卖 1000 $。最终，只有海子出价 500 $。当时，我认为这个机会价值还是挺大的，海子本质上是一个愿意花钱投资的人，所以拒绝了。

之后思考，海子是一个愿意投资机会的人，但是他当时手里有几笔房子的带款，而且现金也不充足，所以没有购买这个机会。我只考虑了海子的性格，没有考虑他当时手里的资金，所以，错失了这笔交易。

游戏和自己现实生活中的关系

什么才算财务自由？现实中很多人说有多少多少百万，有说 500 W的，有说 1000 W的。但是这个游戏告诉我们：只要你的非工作收入超过了你的支出，你就实现了财务自由。跟你手里有多少现金是没有关系的。

唯一的目标就是，增加你的非工作收入，减少你的支出，让你的非工作收入超过你的支出。

这个游戏带给我的收获和启发

人这一生，有的人运气好，能碰到很多次大机会。有的人运气不好，可能一生也没什么机会。

不管如何，你需要在一开始就制定好你做决策的依据。这个依据就是你手里的现金流以及你能承受的风险。

你不应该拿手里的大部分现金去投资一个低收益率高风险的产品，但是也不应该守着一大笔资金不做任何投资。

这个决策依据能够让你在没机会的时候，不至于很快破产。也能让你在有机会的时候，能够快速收获第一桶金，实现财务自由。

对我现实的改变

应该去践行的

从春节前到现在，一个半月没更新了，做啥都提不起劲来。

越来越感觉我的人生过的好失败。

去年我爸因为癌症去世了，家里的门头房用不到了，就想卖掉，找好了买家，价格谈了 140 万。

当时想买我们这个房子的人很多，那个买家怕我们卖给别人，就拿了 20 万定金，和我们签了一个买房合同。

没想到因为这个房子因为在我爸名下，涉及到继承，需要我奶奶放弃继承才可以过户。

我奶奶现在生活不能自理，由我大娘二大娘养着，然后他们提出条件来，要我们的宅基地，也就是村里的老房子。

我妈开始不同意，因为她想之后从那里出殡，和我爸合葬。

后来也同意了，在哪不能殡出去呢？

然后我这边准备好了材料之后，我堂姐跳了出来，一拍桌说，不行，老房子我们也要，另外你还要给我们 25 万。

她们说咨询了律师要是打官司的话，我们青岛的房子也要分，那个门头房也要分，另外我爸的银行流水也要查，起码得分她们 40 万。

我给讲价到了 20 万，但是我妈不同意，说是她和我爸辛苦攒下的家业凭什么白给他们。

我妈这边也找了律师，给出的意见就是拖着就行，一辈子不卖了。

这时候买房子的不干了，说是合同上写了，如果违约，要双倍返回定金，也就是赔她们 20 万。

当时我们以为就是个收到条就签了，没想到在这等着呢。

其实我们早就把定金返给她了，也说了我们家的情况，但她就是不行。

年前就一直威胁我们要告，刚过完年，马上又来了：

我妈问了下和谈的话怎么谈，她说起诉你赔我 25 万，和谈赔我 18 万。

两头挤我们，家里就要我们老房子 + 21 万，卖房子的就要我们 20 万违约金。

我们夹在中间，几度濒临崩溃。

我想了下，这件事早晚得解决，反正都是一家人，给家里人点钱也没啥。

然后我前几天去找我大爷二大爷，还有堂姐、堂哥坐在一起谈了，我说我同意这 21 万。

最终转了她们 18 万（老房子折合了 2 万块），然后又拿了 1 万律师费（他们请的律师让我拿律师费），还有同意给他们老房子。

但我提的要求是和我妈只能说是 10 万 + 老房子，不然我妈不会同意的。

就这样，我们顺利公证过了户。

公证放弃继承那天，我奶奶才刚知道这个事，她说她只要老房子，不要我爸的其他遗产。

但没办法，她不要不行，我大爷二大爷要啊。

这个房子卖了，到手 120 万。

然后还有青岛的房子，这个房子我买的时候是 70万首付 + 100 万带款，一共是 200 万下来的，最近我妈又花了 7 万装修。

因为不去青岛住，也打算卖了，中介说价格不到 80 万还是可以卖掉的。

这么一算，这边亏了 120 万，那边房子卖了剩下 120，相当于我爸就给我留下了 70 多万还不好卖的房子。

其实我爸这辈子攒了不少钱，差不多 300 万，都是省出来的，从小我跟着他就是一天吃一顿那种，从没感觉到家里是有钱的。

再就是他对我妈也不好，前几年的时候经常打骂，后来我妈离家出走了，但是他生病了还是会来照顾他。

我爸癌症住院那段时间，生活不能自理，都是我妈没日没夜的照顾他。

临走之前，我爸一只手抓着我的手，一只手抓着我妈的手，然后让我们好好相处，他一直觉得对不起我妈，口里一直喊着“从头再来、从头再来”。

我送我爸去火葬场的时候，送我骨灰盒爸入土的时候，我也一直在说，“爸，你别怕，我们从头再来”。

其实我爸葬礼上，我没有咋哭出来，可能当时没大反应过来。

但是之后好长一段时间，我在村里别人家坐着聊天，一谈起我爸，就再也忍不住了，哭的稀里哗啦的。

我有个干兄弟，在村里拜了干爹，因为疫情好多年也没走动了，但是我爸的棺材是他帮忙抬出去的。

而我大爷二大爷就在一边看着。

我今年过年给他家送了礼，我说，我妈说我爸是你们抬出去的，让我一辈子记得你们的好。

当时说到这里，没忍住，又哭的稀里哗啦的。

我想我爸这辈子，是攒了不少钱，但是不舍得吃不舍得喝的，还在房子上亏了半辈子的积蓄。

对老婆孩子不好，临走前才后悔想着从头再来。

我想我前五年是赚了不少钱，但因为工作，好多年没回家，和家人一年待在一起也就几天。

而且最后都赔在青岛的房子上了。

人这一辈子，到底图啥呢?

年后这几周我找了找工作，有几个不错的 offer，都是 base 40+ 那种。

但我又不那么想出去了。

我这一年没工作，其实和我妈在一块生活还是很踏实的。

而且家里房子卖了，青岛的房子也快了，这样我的存款差不多能到 300w。存定期的话每年银行利息 8w 左右，够我生活了。

就这样在家躺平一辈子是不是也不错。

王小波说，那一天我二十一岁，在我一生的黄金时代，我有好多奢望。我想爱，想吃，还想在一瞬间变成天上半明半暗的云，后来我才知道，生活就是个缓慢受锤的过程，人一天天老下去，奢望也一天天消逝，最后变得像挨了锤的牛一样。可是我过二十一岁生日时没有预见到这一点。我觉得自己会永远生猛下去，什么也锤不了我。

韩寒说，平凡才是唯一的答案。

小的时候，我希望长大后的自己会光芒万丈。

长大以后，我希望自己有个好的工作打工到退休。

现在的我只想躺平。

我觉得我自己的人生很失败：

打工这些年，钱都赔在房子上了。

我比较社恐，永远达不到我妈对我的会来事、会察言观色的期望。

人家都在大城市结婚生子、买房定居了，而我又回到了小县城。

当年和我同时入职高德的朋友都升 p7 了，我现在啥也不是:

我是 94 年的，今年就 30 了，人生的各种机会和可能性越来越少。

后半辈子，我应该就是在小县城躺平，度过余生了。

但文章我还是想继续写，毕竟人这一生总要坚持点什么。

大家好，作为今年刚毕业的大聪明（小🐂🐎），知道今年不好就业，费心费力的面试终于进了个小公司，然后我的奇妙之旅开始了。

叮！闹钟响了！牙都不刷了，直接起床出门去上班，身为🐂🐎就要有早起吃草干活的觉悟，所以我是个很合格的食草动物。只不过，下面的信息，让我一天当动物的好心情都没了。

部署？因为该公司人数比较少，也没有自动化部署操作，只能让前端build一下dist包然后丢给后端，让后端部署，然后该项目也比较急，我刚来，也不好意思@后端，恰巧跟我对接的后端也是刚来不熟悉，所以我就跟负责人继续扯皮拖延时间了。（真是不好意思，假的）↓↓↓

终于经过不断努力（后端），部署好了，但是，我的样式乱了，为什么呢？看了一下网络和源代码，样式文件都请求到了，问了后端，一致说是我前端的问题，我懵了，然后快马加鞭查找问题

解决

ok，那我先看打包的dist文件有样式有问题吗，使用npm安装个 http-server 运行打包后的index.html，运行打开运行后的地址，欧克样式没乱，文件引用也没问题，那到底是什么鬼影响的呢？

在我百思不得其解的时候，我打开了神器--csdn，搜索打包dist部署后样式文件不生效，就遇到了这个神文t.csdnimg.cn/WbQyq
欧克，按照博主说的Nginx没有配置这两个东西而导致的，我有点不确定是不是，有点犹犹豫豫的找到后端说帮我在Nginx配置文件的http加下这两个配置，然后样式就好了，完美！后端由于疏忽，没加上就把问题推给我，结果被我扳回一城。

include   mime.types;

default_type  application/octet-stream;

总之，添加 include mime.types; 和 default_type application/octet-stream; 配置后，Nginx能够正确地识别和处理CSS文件的MIME类型，从而确保浏览器能够正确加载和应用CSS样式。

所以，前端仔不能只当前端仔，还是要好好学点服务端的知识，不然锅给你，你还认为这是你该背的锅。

以上是开玩笑的描述，只是为了吸引增加阅读量

在一个美好的周末，闲来无事，约上朋友一起在家打麻将，奈何尘封已久的麻将包里翻来翻去也没找到骰子的踪影，于是想在网上找一个骰子模拟器来代替，找了半天都没有发现一款合适好用的软件，于是心血来潮，打算自己做一个🎲模拟器。

1.制定需求设计以及技术方案

1.骰子模型

• 用户可以选择多种骰子模型，如六面 15面 20面等不同风格的供选择


• 并且可以选择要投掷骰子的数量 暂定1-10

2.分数计算规则

• 每次投掷完后会自动计算总点数并显示在屏幕上


• 可以保存历史摇骰子记录 最多支持历史100条记录


• 可以自定义用户参与摇骰子，投掷完成后会显示：luke摇出了xx点。。并且保存在历史记录中


• 支持多人参与摇骰子比赛：比如先加入4名玩家，开始后会依次提示轮到哪位玩家来开始投掷，并且可以选择每局大家需要投掷的次数，最后会统计总点数以及排名。

3.动画特效

• 每次投掷时对骰子随机一个角度以及投掷方向，如果同时投掷多个骰子则随机每一个骰子的角度，给骰子施加一个向赌盘中心的力，让骰子随机落在赌盘中部，在赌盘周围增加一道空气墙来阻止骰子移动到牌桌外。


• 模拟不同骰子的落地音效

4.技术实现

• 利用threejs来实现webgl相关渲染。如骰子模型、场景渲染、相机、棋盘等。


• 利用cannosjs来模拟物理引擎。如骰子碰撞检测、抛出坠落动画、重力加速等物理效果。

2.效果展示

3.开始实现

准备3d骰子模型和棋盘素材

首先是找到合适的gltf模型，这里我们在sketchfab上找到了一款质感很真实的骰子模型。下载下来的模型可以通过gltf-viewer来查看模型效果。
棋盘的话其实是一张图片平铺起来的，这里我用了一张木地板图片。

引入资源以及初始化webgl场景

import * as CANNON from "cannon-es";

import * as THREE from 'three';

import { OrbitControls } from 'three/addons/controls/OrbitControls.js';

import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';

import { GUI } from 'three/addons/libs/lil-gui.module.min.js';





const scene = new THREE.Scene();

const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);

const renderer = new THREE.WebGLRenderer();

renderer.setSize(window.innerWidth, window.innerHeight);

document.body.appendChild(renderer.domElement);



//创建物理世界对象

const world = new CANNON.World();

// 设置物理世界重力加速度

world.gravity.set(0, -100, 0);  //重力加速度： 单位：m/s²

创建物理模型、地面以及网格模型地面

这里简单叙述一下物理世界和webgl世界的联系以及如何在webgl场景里模拟出真实的物理效果。

• 首先在three创建的webgl场景是无法直接创建并感知到物理世界的，threejs只负责实时渲染物理的状态并展示在画布上。而cannos恰好相反，它不负责渲染，只负责创建一个物理世界以及具备物理引擎的物体，并根据物体状态实时计算物体的位置、角度等。并把这些信息实时同步给webgl场景中的模型，把模型渲染到页面上实现物理世界的可视化。


• 所以我们创建骰子、地面等模型都需要创建两份。一份在webgl中创建，一份在物理世界中创建，并且保持同样的尺寸。
  
  

    //创建骰子网格模型（gltf模型）
  
    const loader = new GLTFLoader();
  
    const gltf = await loader.loadAsync('./assets/model/dice_model.glb');
  
  
  
    const meshModel = gltf.scene;//获取箱子网格模型
  
    meshModel.position.set(50,30,50);
  
    meshModel.scale.set(5,5,5);
  
    scene.add(meshModel);
  
  
  
    //包围盒计算
  
    const box3 = new THREE.Box3();
  
    box3.expandByObject(meshModel);//计算模型包围盒
  
    const size = new THREE.Vector3();
  
    box3.getSize(size);//包围盒计算箱子的尺寸
  
  
  
    // 创建骰子物理模型
  
    const sphereMaterial = new CANNON.Material()//碰撞体材质
  
    // 物理正方体
  
    const bodyModel = new CANNON.Body({
  
        mass: 0.3, // 碰撞体质量0.3kg
  
        position: new CANNON.Vec3(50,30,50), // 位置
  
        shape: new CANNON.Box(new CANNON.Vec3(size.x/2, size.y/2, size.z/2)),
  
        material: sphereMaterial
  
    });
  
    
  
    
  
    // 物理地面
  
    const groundMaterial = new CANNON.Material()
  
    const groundBody = new CANNON.Body({
  
        mass: 0, // 质量为0，始终保持静止，不会受到力碰撞或加速度影响
  
        shape: new CANNON.Plane(),
  
        material: groundMaterial,
  
    });
  
    // 改变平面默认的方向，法线默认沿着z轴，旋转到平面向上朝着y方向
  
    groundBody.quaternion.setFromEuler(-Math.PI / 2, 0, 0);//旋转规律类似threejs 平面
  
    world.addBody(groundBody)
  
  
  
    //设置物理世界参数
  
    const contactMaterial = new CANNON.ContactMaterial(groundMaterial, sphereMaterial, {
  
        restitution: 0.5, //反弹恢复系数
  
    })
  
    // 把关联的材质添加到物理世界中
  
    world.addContactMaterial(contactMaterial)
  
  
  
  
  
    // 网格地面
  
    const planeGeometry = new THREE.PlaneGeometry(1000, 1000);
  
    const texture = new THREE.TextureLoader().load('./assets/textures/hardwood2_diffuse.jpg');
  
    texture.wrapS = THREE.RepeatWrapping;
  
    texture.wrapT = THREE.RepeatWrapping;
  
    texture.repeat.set(10, 10);
  
    const planeMaterial = new THREE.MeshLambertMaterial({
  
        // color:0x777777,
  
        map: texture,
  
    });
  
    const planeMesh = new THREE.Mesh(planeGeometry, planeMaterial);
  
    planeMesh.rotateX(-Math.PI / 2);
  
    scene.add(planeMesh);
  
  

  
  

创建好模型后，我们在创建光源，相机等，这里就不再赘述。接下来我们开始设计物理世界的骰子抛出后坠落效果，并将物理世界和webgl渲染同步。

    //点击屏幕后，设置物理骰子的角度和速度，物理会向上抛出并随着重力下落，触碰到地面后则会发生碰撞反弹

    renderer.domElement.addEventListener('click', function (event) {

        start_throw = true;

        clearPoints();

        const randomEuler = Math.random()*3;

        bodyModel.quaternion.setFromEuler(Math.PI / randomEuler, Math.PI / randomEuler, Math.PI / randomEuler);

        bodyModel.position.set(0,50,0);//点击按钮，body回到下落的初始位置

        // 为物体设置初始速度（用以产生抛物线效果）

        bodyModel.velocity.set(option.x,option.y,option.z); // x, y, z 方向上的速度

        // 选中模型的第一个模型，开始下落

        world.addBody(bodyModel);

    })

    

    function render() {

        world.step(1/60);//更新物理计算

        meshModel.position.copy(bodyModel.position);  //渲染循环中，同步物理球body与网格球mesh的位置

        meshModel.quaternion.copy(bodyModel.quaternion);   //同步姿态角度

        locateView();   //相机跟随物体移动

        requestAnimationFrame(render);

        renderer.render(scene, camera);

        if (isBodyStopped(bodyModel)&&start_throw) {

            showPoints();   //停止运动后，显示点数

            start_throw = false;

        }

    }

    render();//根据帧数渲染

    

接下来，我们再添加骰子点数计算相关逻辑。

//获取朝上面的点数

function getUpperFace(mesh) {

    // 定义每个面的局部法线向量（手动定义）

    const localNormals = [

        new THREE.Vector3(0, 1, 0),  // 面1

        new THREE.Vector3(0, 0, -1),  // 面2

        new THREE.Vector3(-1, 0, 0), // 面3

        new THREE.Vector3(1, 0, 0),  // 面4

        new THREE.Vector3(0, 0, 1),  // 面5

        new THREE.Vector3(0, -1, 0), // 面6

    ];

    

    let maxDot = -Infinity;

    let faceValue = 0;

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

        // 将局部法线向量转化为世界空间

        const worldNormal = localNormals[i].clone().applyQuaternion(mesh.quaternion);

    

        // 与全局上方向的点积

        const dot = worldNormal.dot(new THREE.Vector3(0, 1, 0));

    

        // 检查点积，找到最大值

        if (dot > maxDot) {

            maxDot = dot;

            faceValue = i + 1; // 面的点数即为索引加1

        }

    }

    

    return faceValue;

}

//判断物体是否停止运动

function isBodyStopped(body, linearVelocityThreshold = 0.1, angularVelocityThreshold = 0.1) {

    // 获取物体的线性速度和角速度

    const linearVelocityMagnitude = body.velocity.length();

    const angularVelocityMagnitude = body.angularVelocity.length();



    // 判断速度是否低于设定的阈值

    return linearVelocityMagnitude < linearVelocityThreshold && angularVelocityMagnitude < angularVelocityThreshold;

}

//展示点数

function showPoints() {

    let res = getUpperFace(meshModel);

    let point = document.getElementById("points");

    point.innerHTML = `点数：${res}`

}

//清空点数

function clearPoints() {

    let point = document.getElementById("points");

    point.innerHTML = ``

}

实现这些逻辑后，我们已经可以模拟出骰子抛出坠落并触碰地面后反弹，在停止运动后计算点数的效果。已经实现基础功能，但是我们发现如果随机速度过大的时候会移动很远才停下，于是我们增加一个空气墙来限制骰子在固定范围内。并且增加一个碰撞检测来触发撞地声音的效果。

//添加空气墙

const wallShape = new CANNON.Box(new CANNON.Vec3(100, 100, 0.1));

    

const wall1 = new CANNON.Body({ mass: 0 });

wall1.addShape(wallShape);

wall1.position.set(0, 100, -100); // Back wall

world.addBody(wall1);



const wall2 = new CANNON.Body({ mass: 0 });

wall2.addShape(wallShape);

wall2.position.set(0, 100, 100); // Front wall

world.addBody(wall2);



const wall3 = new CANNON.Body({ mass: 0 });

wall3.addShape(wallShape);

wall3.quaternion.setFromEuler(0, Math.PI / 2, 0); // Rotate for side walls

wall3.position.set(100, 100, 0); // Right wall

world.addBody(wall3);



const wall4 = new CANNON.Body({ mass: 0 });

wall4.addShape(wallShape);

wall4.quaternion.setFromEuler(0, Math.PI / 2, 0); // Rotate for side walls

wall4.position.set(-100, 100, 0); // Left wall

world.addBody(wall4);



//监听物体碰撞回调

const audio = new Audio('./assets/audio/peng.mp3');

bodyModel.addEventListener('collide', (event) => {

    const contact = event.contact;

    //获得沿法线的冲击速度

    const ImpactV = contact.getImpactVelocityAlongNormal();

    // 碰撞越狠，声音越大

    if(ImpactV/35>1) {

        audio.volume = 1;

    } else {

        audio.volume = ImpactV/35>0?ImpactV/35:0;

    }

    audio.currentTime = 0;

    audio.play();

})

这样我们就初步完成了抛掷一个骰子并获取点数的功能，看似简单的一个场景实际上设计起来并不容易，要考虑很多因素。后续我会继续增加多个骰子同时抛掷的场景，以及比赛模式。源码也会贡献出来供大家一起学习参考，如果有更好的idea也可以在评论区留言或私信，大家一起在webgl中感受物理世界的魅力！

• 效果展示：codesandbox.io/p/github/lu…


• 源码地址：github.com/lukeSuperCo…

附完整代码：

import * as CANNON from "cannon-es";

import * as THREE from 'three';

import { OrbitControls } from 'three/addons/controls/OrbitControls.js';

import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';

import { GUI } from 'three/addons/libs/lil-gui.module.min.js';





const scene = new THREE.Scene();

const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);

const renderer = new THREE.WebGLRenderer();

renderer.setSize(window.innerWidth, window.innerHeight);

document.body.appendChild(renderer.domElement);



// 实例化一个gui对象

// const gui = new GUI();

// //改变交互界面style属性

// gui.domElement.style.right = '0px';

// gui.domElement.style.width = '300px';



const option = {

    z: -24,

    x: -36,

    y: -17,

    z1: 1,

    x1: 1,

    y1: 1,

}

// //gui控制参数

// const folder_position = gui.addFolder('速度方向');

// folder_position.add(option, 'z', -100, 100);

// folder_position.add(option, 'x', -100, 100);

// folder_position.add(option, 'y', -100, 100);

// const folder_rotation = gui.addFolder('角度');

// folder_rotation.add(option, 'z1', -10, 10).step(0.1);

// folder_rotation.add(option, 'x1', -10, 10).step(0.1);

// folder_rotation.add(option, 'y1', -10, 10).step(0.1);



// CANNON.World创建物理世界对象

const world = new CANNON.World();

// 设置物理世界重力加速度

// world.gravity.set(0, -1000, 0); //重力加速度： 单位：m/s²

world.gravity.set(0, -100, 0);









//网格球体（gltf模型）

const loader = new GLTFLoader();

const gltf = await loader.loadAsync('./assets/model/dice_model.glb');



const meshModel = gltf.scene;//获取箱子网格模型

meshModel.position.set(50,30,50);

meshModel.scale.set(5,5,5);

scene.add(meshModel);



//包围盒计算

const box3 = new THREE.Box3();

box3.expandByObject(meshModel);//计算模型包围盒

const size = new THREE.Vector3();

box3.getSize(size);//包围盒计算箱子的尺寸



// 物理球体

const sphereMaterial = new CANNON.Material()//碰撞体材质

// 物理箱子

const bodyModel = new CANNON.Body({

    mass: 0.3, // 碰撞体质量0.3kg

    position: new CANNON.Vec3(50,30,50), // 位置

    shape: new CANNON.Box(new CANNON.Vec3(size.x/2, size.y/2, size.z/2)),

    material: sphereMaterial

});



// 骨骼辅助显示

const skeletonHelper = new THREE.SkeletonHelper(meshModel);

scene.add(skeletonHelper);



// world.addBody(bodyModel);



//添加空气墙

// Create air walls

const wallShape = new CANNON.Box(new CANNON.Vec3(100, 100, 0.1));

    

const wall1 = new CANNON.Body({ mass: 0 });

wall1.addShape(wallShape);

wall1.position.set(0, 100, -100); // Back wall

world.addBody(wall1);



const wall2 = new CANNON.Body({ mass: 0 });

wall2.addShape(wallShape);

wall2.position.set(0, 100, 100); // Front wall

world.addBody(wall2);



const wall3 = new CANNON.Body({ mass: 0 });

wall3.addShape(wallShape);

wall3.quaternion.setFromEuler(0, Math.PI / 2, 0); // Rotate for side walls

wall3.position.set(100, 100, 0); // Right wall

world.addBody(wall3);



const wall4 = new CANNON.Body({ mass: 0 });

wall4.addShape(wallShape);

wall4.quaternion.setFromEuler(0, Math.PI / 2, 0); // Rotate for side walls

wall4.position.set(-100, 100, 0); // Left wall

world.addBody(wall4);



camera.position.set(42,85,21)

camera.lookAt(0,10,0);



// 物理地面

const groundMaterial = new CANNON.Material()

const groundBody = new CANNON.Body({

    mass: 0, // 质量为0，始终保持静止，不会受到力碰撞或加速度影响

    shape: new CANNON.Plane(),

    material: groundMaterial,

});

// 改变平面默认的方向，法线默认沿着z轴，旋转到平面向上朝着y方向

groundBody.quaternion.setFromEuler(-Math.PI / 2, 0, 0);//旋转规律类似threejs 平面

world.addBody(groundBody)



//设置物理世界参数

const contactMaterial = new CANNON.ContactMaterial(groundMaterial, sphereMaterial, {

    restitution: 0.5, //反弹恢复系数

})

// 把关联的材质添加到物理世界中

world.addContactMaterial(contactMaterial)



//光源设置

const directionalLight = new THREE.DirectionalLight(0xffffff, 2);

directionalLight.position.set(20, 100, 10);

scene.add(directionalLight);





// 网格地面

const planeGeometry = new THREE.PlaneGeometry(1000, 1000);

const texture = new THREE.TextureLoader().load('./assets/textures/hardwood2_diffuse.jpg');

texture.wrapS = THREE.RepeatWrapping;

texture.wrapT = THREE.RepeatWrapping;

texture.repeat.set(10, 10);

const planeMaterial = new THREE.MeshLambertMaterial({

    // color:0x777777,

    map: texture,

});

const planeMesh = new THREE.Mesh(planeGeometry, planeMaterial);

planeMesh.rotateX(-Math.PI / 2);

scene.add(planeMesh);



// 添加一个辅助网格地面

// const gridHelper = new THREE.GridHelper(50, 50, 0x004444, 0x004444);

// scene.add(gridHelper);





var controls = new OrbitControls(camera, renderer.domElement);

controls.enableDamping = true; // 允许阻尼效果

controls.dampingFactor = 0.25; // 阻尼系数



let start_throw = false;

renderer.domElement.addEventListener('click', function (event) {

    start_throw = true;

    clearPoints();

    const randomEuler = Math.random()*3;

    bodyModel.quaternion.setFromEuler(Math.PI / randomEuler, Math.PI / randomEuler, Math.PI / randomEuler);

    bodyModel.position.set(0,50,0);//点击按钮，body回到下落的初始位置

    // 为物体设置初始速度（用以产生抛物线效果）

    bodyModel.velocity.set(option.x,option.y,option.z); // x, y, z 方向上的速度

    // 选中模型的第一个模型，开始下落

    world.addBody(bodyModel);

})

const audio = new Audio('./assets/audio/peng.mp3');

bodyModel.addEventListener('collide', (event) => {

    const contact = event.contact;

    //获得沿法线的冲击速度

    const ImpactV = contact.getImpactVelocityAlongNormal();

    // 碰撞越狠，声音越大

    if(ImpactV/35>1) {

        audio.volume = 1;

    } else {

        audio.volume = ImpactV/35>0?ImpactV/35:0;

    }

    audio.currentTime = 0;

    audio.play();

})



//判断物体是否停止运动

function isBodyStopped(body, linearVelocityThreshold = 0.1, angularVelocityThreshold = 0.1) {

    // 获取物体的线性速度和角速度

    const linearVelocityMagnitude = body.velocity.length();

    const angularVelocityMagnitude = body.angularVelocity.length();



    // 判断速度是否低于设定的阈值

    return linearVelocityMagnitude < linearVelocityThreshold && angularVelocityMagnitude < angularVelocityThreshold;

}



function showPoints() {

    let res = getUpperFace(meshModel);

    let point = document.getElementById("points");

    point.innerHTML = `点数：${res}`

}



//相机跟随物体移动

function locateView() {

    camera.position.x = meshModel.position.x;

    camera.position.y = meshModel.position.y + 30;

    camera.position.z = meshModel.position.z + 20;

    camera.lookAt(meshModel.position)

}



function clearPoints() {

    let point = document.getElementById("points");

    point.innerHTML = ``

}

//获取朝上面的点数

function getUpperFace(mesh) {

    // 定义每个面的局部法线向量（手动定义）

    const localNormals = [

        new THREE.Vector3(0, 1, 0),  // 面1

        new THREE.Vector3(0, 0, -1),  // 面2

        new THREE.Vector3(-1, 0, 0), // 面3

        new THREE.Vector3(1, 0, 0),  // 面4

        new THREE.Vector3(0, 0, 1),  // 面5

        new THREE.Vector3(0, -1, 0), // 面6

    ];

    

    let maxDot = -Infinity;

    let faceValue = 0;

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

        // 将局部法线向量转化为世界空间

        const worldNormal = localNormals[i].clone().applyQuaternion(mesh.quaternion);

    

        // 与全局上方向的点积

        const dot = worldNormal.dot(new THREE.Vector3(0, 1, 0));

    

        // 检查点积，找到最大值

        if (dot > maxDot) {

            maxDot = dot;

            faceValue = i + 1; // 面的点数即为索引加1

        }

    }

    

    return faceValue;

}

function render() {

    world.step(1/60);//更新物理计算

    meshModel.position.copy(bodyModel.position);  //渲染循环中，同步物理球body与网格球mesh的位置

    meshModel.quaternion.copy(bodyModel.quaternion);   //同步姿态角度

    locateView();   //相机跟随物体移动

    requestAnimationFrame(render);

    renderer.render(scene, camera);

    if (isBodyStopped(bodyModel)&&start_throw) {

        showPoints();   //停止运动后，显示点数

        start_throw = false;

    }

}

render();

因为工作的原因，我和一些外国前端开发有些交流。他们对于国内环境不了解，有时候会问出一些有趣的问题，大概是这些问题的启发，让我反复在思考一些更为深入的问题。

今天聊三个事情：

• 小程序
• 微前端
• 模块加载

小程序

每个行业都有一把银座，当坐上那把银座时，做什么便都是对的。

“我们为什么需要小程序？”

第一次被问到这个问题，是因为一个法国的同事。他被派去做一个移动端业务，刚好那个业务是采用小程序在做。于是一个法国小哥就在被痛苦的中文文档和黑盒逻辑中来回折磨着 🤦。

于是，当我们在有一次交流中，他问出了我这个问题：我们为什么需要小程序？

说实话，我试图解释了 19 年国内的现状，以及微信小程序推出时候所带来的便利和体验等等。总之，在我看来并不够深刻的见解。

即便到现在为止，每次当我使用小程序的时候，依旧会复现这个问题。在 ChatGPT 11 月份出来的时候，我也问了它这个很有国内特色的问题：

看起来它回答的还算不错，至少我想如果它来糊弄那些老外，应该会比我做的更好些。

但如果扪心自问，单从技术上来讲。以上这些事情，一定是有其他方案能解决的。

所以从某种程度上来看，这更像是一场截胡的商业案例：

应用市场

全世界的互联网人都知道应用市场是非常有价值的事情，可以说操作系统最值钱的部分就在于他们构建了自己的应用市场。

只要应用在这里注册发行，雁过拔毛，这家公司就是互联网世界里的统治阶级，规则的制定者。

反之则需要受制于人，APP 做的再大，也只是应用市场里的一个应用，做的好与坏还得让应用商店的评判。

另外，不得不承认的是，一个庞大如苹果谷歌这样的公司，他们的应用商店对于普通国内开发者来说，确实是有门槛的。

在国内海量的 APP 需求来临之前，能否提供一个更低成本的解决方案，来消化这些公司的投资？

毕竟不是所有的小企业都需要 APP，其实他们大部分需求 Web 就可以解决，但是 Web 没牌面啊，做 Web 还得砸搜索的钱才有流量。(某度搜索又做成那样...)

那做操作系统？太不容易，那么多人都溺死在水里了，这水太深。

那有没有一种办法可以既能构建生态，又有 APP 的心智，还能给入驻企业提供流量？

于是，在 19 年夏天，滨海大厦下的软件展业基地里，每天都在轮番播放着，做 XX小程序，拥抱下一个风口...

全新体验心智

小程序用起来挺方便的。

你有没有想过，这些美妙感觉的具体都来自哪些？以及这些真的是 Web 技术本身无法提供的吗？

1. 靠谱感，每个小程序都有约束和规范，于是你可以将他们整整齐齐的陈放在你的列表里，仿佛你已经拥有了这一个个精心雕琢的作品，相对于一条条记不住的网页地址和鱼龙混杂的网页内容来说，这让你觉得小程序更加的有分量和靠谱。
2. 安全感，沉浸式的头部，没有一闪而过的加载条，这一切无打扰的设计，都让你觉得这是一个在你本地的 APP，而不是随时可能丢失网页。你不会因为网速白屏而感到焦虑，尽管网络差的时候，你的 KFC 依旧下不了单 😂
3. 沉浸感，我不知道是否打开网页时顶部黑黑的状态栏是故意留下的，还是不小心的... 这些限制都让用户非常强烈的意识到这是一个网页而不是 APP，而小程序中虽然上面也存在一个空间的空白，但是却可以被更加沉浸的主题色和氛围图替代。网页这个需求做不了？我不信。

H5	小程序

4. 顺滑感，得益于 Native 的容器实现，小程序在所有的视图切换时，都可以表现出于原生应用一样的顺滑感。其实这个问题才是在很多 Hybrid 应用中，主要想借助客户端来处理和解决的问题。类似容器预开、容器切换等技术是可以解决相关问题的，只是还没有一个标准。

我这里没有提性能，说实话我不认为性能在小程序中是有优势的（Native 调用除外，如地图等，不是一个讨论范畴）。作为普通用户，我们感受到的只是离线加载下带来的顺滑而已。

而上述提到的许多优势，这对于一个高品质的 Web 应用来说是可以做得到的，但注意这里是高品质的 Web 应用。而这种“高品质”在小程序这里，只是入驻门槛而已。

心智，这个词，听起来很黑话，但却很恰当。当小程序通过长期这样的筛选，所沉淀出来一批这样品质的应用时。就会让每个用户即便在还没打开一个新的小程序之前，也有不错体验的心理预期。这就是心智，一种感觉跟 Web 不一样，跟 APP 有点像的心智。

打造心智，这件事情好像就是国内互联网企业最擅长做的事情，总是能从一些细微的差别中开辟一条独立的领域，然后不断强化灌输本来就不大的差异，等流量起来再去捞钱变现。