前言

hi，大家好，我是大鱼七成饱。

前几天同事review我的代码，发现mapstruct有这么多好用的技巧，遇到POJO转换的问题经常过来沟通。考虑到不可能每次都一对一，所以我来梳理五个场景，谁在过来问，直接甩出总结。

环境准备

由于日常使用都是spring，所以后面的示例都是在springboot框架中运行的。关键pom依赖如下：

<properties>

        <java.version>1.8</java.version>

        <org.mapstruct.version>1.5.5.Final</org.mapstruct.version>

        <org.projectlombok.version>1.18.30</org.projectlombok.version>

    </properties>

    <dependencies>



        <dependency>

            <groupId>org.mapstruct</groupId>

            <artifactId>mapstruct</artifactId>

            <version>${org.mapstruct.version}</version>

        </dependency>

        <dependency>

            <groupId>org.mapstruct</groupId>

            <artifactId>mapstruct-processor</artifactId>

            <version>${org.mapstruct.version}</version>

        </dependency>



        <dependency>

            <groupId>org.projectlombok</groupId>

            <artifactId>lombok</artifactId>

            <optional>true</optional>

            <scope>provided</scope>

        </dependency>



        <dependency>

            <groupId>org.projectlombok</groupId>

            <artifactId>lombok-mapstruct-binding</artifactId>

            <version>0.2.0</version>

        </dependency>



        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter</artifactId>

        </dependency>



        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-test</artifactId>

            <scope>test</scope>

        </dependency>

    </dependencies>



    <build>

        <plugins>

            <plugin>

                <groupId>org.springframework.boot</groupId>

                <artifactId>spring-boot-maven-plugin</artifactId>

            </plugin>

        </plugins>

    </build>

场景一：常量转换

这是最简单的一个场景，比如需要设置字符串、整形和长整型的常量，有的又需要日期，或者新建类型。下面举个例子，演示如何转换

//实体类

@Data

public class Source {

    private String stringProp;

    private Long longProp;

}

@Data

public class Target {

    private String stringProperty;

    private long longProperty;

    private String stringConstant;

    private Integer integerConstant;

    private Long  longWrapperConstant;

    private Date dateConstant;

}

• 设置字符串常量


• 设置long常量


• 设置java内置类型默认值，比如date

那么mapper这么设置就可以

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public interface SourceTargetMapper {



    @Mapping(target = "stringProperty", source = "stringProp", defaultValue = "undefined")

    @Mapping(target = "longProperty", source = "longProp", defaultValue = "-1l")

    @Mapping(target = "stringConstant", constant = "Constant Value")

    @Mapping(target = "integerConstant", constant = "14")

    @Mapping(target = "longWrapperConstant", constant = "3001L")

    @Mapping(target = "dateConstant", dateFormat = "yyyy-MM-dd", constant = "2023-09-")

    Target sourceToTarget(Source s);

}

解释下，constant用来设置常量值，source的值如果没有设置，则会使用defaultValue的值，日期可以按dateFormat解析。

Talk is cheap, show me the code !废话不多说，自动生成的转换类如下：

@Component

public class SourceTargetMapperImpl implements SourceTargetMapper {

    public SourceTargetMapperImpl() {

    }



    public Target sourceToTarget(Source s) {

        if (s == null) {

            return null;

        } else {

            Target target = new Target();

            if (s.getStringProp() != null) {

                target.setStringProperty(s.getStringProp());

            } else {

                target.setStringProperty("undefined");

            }



            if (s.getLongProp() != null) {

                target.setLongProperty(s.getLongProp());

            } else {

                target.setLongProperty(-1L);

            }



            target.setStringConstant("Constant Value");

            target.setIntegerConstant(14);

            target.setLongWrapperConstant(3001L);



            try {

                target.setDateConstant((new SimpleDateFormat("dd-MM-yyyy")).parse("09-01-2014"));

                return target;

            } catch (ParseException var4) {

                throw new RuntimeException(var4);

            }

        }

    }

}

是不是一目了然

场景二：转换中调用表达式

比如id不存在使用UUID生成一个，或者使用已有参数新建一个对象作为属性。当然可以用after mapping，qualifiedByName等实现，感觉还是不够优雅，这里介绍个雅的（代码少点的）。

实体类如下：

@Data

public class CustomerDto {

    public Long id;

    public String customerName;



    private String format;

    private Date time;

}

@Data

public class Customer {

    private String id;

    private String name;

    private TimeAndFormat timeAndFormat;

}

@Data

public class TimeAndFormat {

    private Date time;

    private String format;



    public TimeAndFormat(Date time, String format) {

        this.time = time;

        this.format = format;

    }

}

Dto转customer，加创建TimeAndFormat作为属性，mapper实现如下：

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING, imports = UUID.class)

public interface CustomerMapper {



    @Mapping(target = "timeAndFormat",

            expression = "java( new TimeAndFormat( s.getTime(), s.getFormat() ) )")

    @Mapping(target = "id", source = "id", defaultExpression = "java( UUID.randomUUID().toString() )")

    Customer toCustomer(CustomerDto s);



}

解释下，id为空则走默认的defaultExpression，通过imports引入，java括起来调用。新建对象直接new TimeAndFormat。有的小伙伴喜欢用qualifiedByName自定义方法，可以对比下，哪个合适用哪个，都能调用转换方法。

生成代码如下：

@Component

public class CustomerMapperImpl implements CustomerMapper {

    public CustomerMapperImpl() {

    }



    public Customer toCustomer(CustomerDto s) {

        if (s == null) {

            return null;

        } else {

            Customer customer = new Customer();

            if (s.getId() != null) {

                customer.setId(String.valueOf(s.getId()));

            } else {

                customer.setId(UUID.randomUUID().toString());

            }



            customer.setTimeAndFormat(new TimeAndFormat(s.getTime(), s.getFormat()));

            return customer;

        }

    }

}

场景三：类共用属性，如何复用

比如下面的Bike和车辆类，都有id和creationDate属性，我又不想重复写mapper属性注解

public class Bike {

    /**

     * 唯一id

     */

    private String id;



    private Date creationDate;



    /**

     * 品牌

     */

    private String brandName;

}



public class Car {

    /**

     * 唯一id

     */

    private String id;



    private Date creationDate;

    /**

     * 车牌号

     */

    private String chepaihao;

 }

解决起来很简单，写个共用的注解，使用的时候引入就可以，示例如下：

//通用注解

@Retention(RetentionPolicy.CLASS)

//自动生成当前日期

@Mapping(target = "creationDate", expression = "java(new java.util.Date())")

//忽略id

@Mapping(target = "id", ignore = true)

public @interface ToEntity { }



//使用

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public interface TransportationMapper {

    @ToEntity

    @Mapping( target = "brandName", source = "brand")

    Bike map(BikeDto source);



    @ToEntity

    @Mapping( target = "chepaihao", source = "plateNo")

    Car map(CarDto source);

}

这里Retention修饰ToEntity注解，表示ToEntity注解被保留到class文件，但jvm加载class文件时候被遗弃，这是默认的生命周期，辅助生成mapper实现类。上面定义了creationDate和id的转换规则,新建日期，忽略id。

生成的mapper实现类如下：

@Component

public class TransportationMapperImpl implements TransportationMapper {

    public TransportationMapperImpl() {

    }



    public Bike map(BikeDto source) {

        if (source == null) {

            return null;

        } else {

            Bike bike = new Bike();

            bike.setBrandName(source.getBrand());

            bike.setCreationDate(new Date());

            return bike;

        }

    }



    public Car map(CarDto source) {

        if (source == null) {

            return null;

        } else {

            Car car = new Car();

            car.setChepaihao(source.getPlateNo());

            car.setCreationDate(new Date());

            return car;

        }

    }

}

坚持一下，还剩俩场景，剩下的俩更有意思

场景四：lombok和mapstruct冲突了

啥冲突？用了builder注解后，mapstuct转换不出来了。哎，这个问题困扰了我那同事两天时间。

解决方案如下：

 <dependency>

            <groupId>org.projectlombok</groupId>

            <artifactId>lombok-mapstruct-binding</artifactId>

            <version>0.2.0</version>

 </dependency>

加上lombok-mapstruct-binding就可以了，看下生成的效果：

@Builder

@Data

public class Person {

    private String name;

}

@Data

public class PersonDto {

    private String name;

}

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public interface PersonMapper {



    Person map(PersonDto dto);

}

@Component

public class PersonMapperImpl implements PersonMapper {

    public PersonMapperImpl() {

    }



    public Person map(PersonDto dto) {

        if (dto == null) {

            return null;

        } else {

            Person.PersonBuilder person = Person.builder();

            person.name(dto.getName());

            return person.build();

        }

    }

}

从上面可以看到，mapstruct匹配到了lombok的builder方法。

场景五：说个难点的，转换的时候，如何注入springBean

有时候转换方法比不是静态的，他可能依赖spring bean，这个如何导入？

这个使用需要使用抽象方法了，上代码：

@Component

public class SimpleService {

    public String formatName(String name) {

        return  "您的名字是：" + name;

    }

}

@Data

public class Student {

    private String name;

}

@Data

public class StudentDto {

    private String name;

}

@Mapper(componentModel = MappingConstants.ComponentModel.SPRING)

public abstract class StudentMapper {



    @Autowired

    protected SimpleService simpleService;



    @Mapping(target = "name", expression = "java(simpleService.formatName(source.getName()))")

    public abstract StudentDto map(StudentDto source);

}

接口是不支持注入的，但是抽象类可以，所以采用抽象类解决，后面expression直接用皆可以了，生成mapperimpl如下：

@Component

public class StudentMapperImpl extends StudentMapper {

    public StudentMapperImpl() {

    }



    public StudentDto map(StudentDto source) {

        if (source == null) {

            return null;

        } else {

            StudentDto studentDto = new StudentDto();

            studentDto.setName(this.simpleService.formatName(source.getName()));

            return studentDto;

        }

    }

}

思考

以上场景肯定还有其他解决方案，遵循合适的原则就可以。驾驭不了的代码，可能带来更多问题，先简单实现，后续在迭代优化可能适合更多的业务场景。

本文示例代码放在了github，需要的朋友请关注公众号大鱼七成饱,回复关键词MapStruct使用即可获得。

背景

最近在使用拼多多购物，除了价格比较香之外，每次冷启打开的体验非常好，作为一个Android开发不免好奇 简单分析记录一下

冷启数据

体验好，让我想到了郭德纲的那句话"全靠同行的衬托",那找几个同行过来对比下，这里使用淘宝、京东、闲鱼，从点击开始图标开始录个屏直接数秒，

测试手机是 华为 Mate 60

我这个样本比较少，机器性能也比较好，仅仅是个人对比，不代表大众使用的真实情况

可以粗略的看几个常见app的冷启对比下，这里录屏使用的剪映来分析
帧率为 每秒30帧，后面会涉及一些时间换算

拼多多

无广告冷启动 从点击图标到到首页完整展示 大概花了 29帧，
1000ms * 29/30 约为 0.96s
，太惊人了，基本冷启秒开

拼多多可能真的没有开屏广告，我印象中没有见过拼多多的开屏广告

淘宝

无广告冷启东 从点击图标到到首页完整展示


大概花了 1s+21帧，
1000ms+ 21/30*1000ms = 1.7s
还可以

淘宝可能没有开屏广告，或者非常克制，我刷了十几次都没有见到开屏广告

京东

无广告冷启京东
从点击图标到到首页完整展示

大概花了 1s+28帧，
1000ms + 28/30*1000ms 约为 1.93s
也是不错的

不过京东的开屏有开屏广告，但是做了用户频控，刷了几次就没了，这里仅对比无广告冷启开屏

闲鱼

毕竟是国内最大的二手平台（虽然现在小商家也特别多），而且是flutter深度使用者，看看它的表现


大概花了** 2s+10帧**
2000ms+ 10/30*1000ms 约为 2.3s

从上面数据来看，怪不得 我使用拼多多之后，打开app 确实比较舒服，因为我就是奔着买东西去的，越快到购物页面越舒服的。或许这就是极致的用户体验吧

首屏细节

拼多多的首页数据咋这么快就准备好了，网络耗时应该也有呢，应该是它提前准备好了数据

我们来实操验证下

• 切后台的截图

我们记住 手枪、去虾线、行李箱、停电 这几个卡片

冷启打开之后首先展示的是 还是切后台之前的数据

紧接着网络数据到了做了一次屏幕刷新

到这里大概就明白了，冷启使用上次feeds流的数据，先让用户看到数据，然后等新数据请求到之后再刷新页面就好

为了严谨点，把缓存数据清除的话，那么肯定首次冷启白屏，ok最后再验证一下

此时冷启白茫茫的一片，看来拼多多的策略还是让用户尽快进应用优先，或者这里并没有刻意设计🤔，都是先进首页有缓存就使用 没有的话就等网络数据，毕竟这种情况也只是新用户或者缓存数据过期才会这样

因此这里我可以得出把这种缓存优先的技术方案也可以学习学习，看看我们自己的app是不是可以复用一下，绩效这不就来了吗🤔
首页 = 数据 + UI
数据是使用缓存，UI也能吧一些UI组件提前预加载，不过这里也无法判断 是否预加载了首页UI🤔

开屏无广告

我目前在字节就是搞广告的，所以对广告稍微敏感些，开屏广告是一个很棒收入来源，特别是合约广告这种，之前应用冷启时间长，有时候其实是故意抽出一些时间来等待冷启的开屏广告，
但是我试了很多次，确实没看过拼多多的开屏广告，不过从这个结果来看 肯定是 经过严密的ab实验，不过拼多多在开屏广告上确实比较克制，

关于现在互联网的计算广告业务还是蛮有意思的比如 广告类型有 开屏、原生、激励、插屏、横幅，sdk类型有单个adn或者聚合广告sdk，有时间再单独分享几篇。

冷启优化一些常见手段

冷启动往往是大型应用的必争之地

拼多多技术是应该是有些东西的，但是非常低调，属于人狠话不多那种，也没找到他们的方案。这里结合自身经验聊聊这块，主要是以下4个阶段结合技术手段做优化

Application attachBaseContext

这个阶段由于 Applicaiton Context 赋值等问题，一般不会有太多的业务代码，可能的耗时会在低版本机器4.x机器比较多，首次由于MultiDex.install耗时

dex 的指令格式设计并不完善，单个 dex 文件中引用的 Java 方法总数不能超过 65536 个，在方法数超过 65536 的情况下，将拆分成多个 dex。一般情况下 Dalvik 虚拟机只能执行经过优化后的 odex 文件，在 4.x 设备上为了提升应用安装速度，其在安装阶段仅会对应用的首个 dex 进行优化。对于非首个 dex 其会在首次运行调用 MultiDex.install 时进行优化，而这个优化是非常耗时的，这就造成了 4.x 设备上首次启动慢的问题。

可以使用一些开源方案，比如 github.com/bytedance/B…
不过 这里优化难度比较大，roi的话 看看app低版本的机型占比再做决定

ContentProvider

这里要注意检查 ContentProvider，特别是一些sdk在 AndroidManifest 里面注册了自己的 xxSDkProvider，然后在 xxSDkProvider 的 onCreate 方面里面进行初始化，确实调用者不需要自己初始化了，可却增加了启动耗时，
我们可以打开 Apk，看一下最终merge的 AndroidManiest 里面有多少 provider，看一下是否有这样的骚操作，往往这里容易忽视，这种情况可以使用谷歌App Startup来收敛ContentProvider

Application 优化

西瓜视频 在冷启优化就将 push、小程序、sandboxed这几个进程做了优化拿到一些不错的收益mp.weixin.qq.com/s/v23jEhF9k…

搞进程难度大风险高

3. 启动链路任务编排

在 Spring Boot 框架中，内置了许多实用的功能，这些功能可以帮助开发者高效地开发和维护应用程序。

松哥来和大家列举几个。

一 请求数据记录

Spring Boot提供了一个内置的日志记录解决方案，通过 AbstractRequestLoggingFilter 可以记录请求的详细信息。

AbstractRequestLoggingFilter 有两个不同的实现类，我们常用的是 CommonsRequestLoggingFilter。

通过 CommonsRequestLoggingFilter 开发者可以自定义记录请求的参数、请求体、请求头和客户端信息。

启用方式很简单，加个配置就行了：

@Configuration

public class RequestLoggingConfig {

    @Bean

    public CommonsRequestLoggingFilter logFilter() {

        CommonsRequestLoggingFilter filter = new CommonsRequestLoggingFilter();

        filter.setIncludeQueryString(true);

        filter.setIncludePayload(true);

        filter.setIncludeHeaders(true);

        filter.setIncludeClientInfo(true);

        filter.setAfterMessagePrefix("REQUEST ");

        return filter;

    }

}

接下来需要配置日志级别为 DEBUG，就可以详细记录请求信息：

logging.level.org.springframework.web.filter.CommonsRequestLoggingFilter=DEBUG

二 请求/响应包装器

2.1 什么是请求和响应包装器

在 Spring Boot 中，请求和响应包装器是用于增强原生 HttpServletRequest 和 HttpServletResponse 对象的功能。这些包装器允许开发者在请求处理过程中拦截和修改请求和响应数据，从而实现一些特定的功能，如请求内容的缓存、修改、日志记录，以及响应内容的修改和增强。

请求包装器

• ContentCachingRequestWrapper：这是 Spring 提供的一个请求包装器，用于缓存请求的输入流。它允许多次读取请求体，这在需要多次处理请求数据（如日志记录和业务处理）时非常有用。

响应包装器

• ContentCachingResponseWrapper：这是 Spring 提供的一个响应包装器，用于缓存响应的输出流。它允许开发者在响应提交给客户端之前修改响应体，这在需要对响应内容进行后处理（如添加额外的头部信息、修改响应体）时非常有用。

2.2 使用场景

2.3 具体用法

请求包装器的使用

import org.springframework.web.filter.OncePerRequestFilter;

import javax.servlet.FilterChain;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.io.IOException;



@Component

public class RequestWrapperFilter extends OncePerRequestFilter {

    @Override

    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)

            throws ServletException, IOException {

        ContentCachingRequestWrapper requestWrapper = new ContentCachingRequestWrapper(request);

        // 可以在这里处理请求数据

        byte[] body = requestWrapper.getContentAsByteArray();

        // 处理body，例如记录日志

        //。。。

        filterChain.doFilter(requestWrapper, response);

    }

}

响应包装器的使用

import org.springframework.web.filter.OncePerRequestFilter;

import javax.servlet.FilterChain;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import java.io.IOException;



@Component

public class ResponseWrapperFilter extends OncePerRequestFilter {

    @Override

    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)

            throws ServletException, IOException {

        ContentCachingResponseWrapper responseWrapper = new ContentCachingResponseWrapper(response);

        filterChain.doFilter(request, responseWrapper);



        // 可以在这里处理响应数据

        byte[] body = responseWrapper.getContentAsByteArray();

        // 处理body，例如添加签名

        responseWrapper.setHeader("X-Signature", "some-signature");



        // 必须调用此方法以将响应数据发送到客户端

        responseWrapper.copyBodyToResponse();

    }

}

在上面的案例中，OncePerRequestFilter 确保过滤器在一次请求的生命周期中只被调用一次，这对于处理请求和响应数据尤为重要，因为它避免了在请求转发或包含时重复处理数据。

通过使用请求和响应包装器，开发者可以在不改变原有业务逻辑的情况下，灵活地添加或修改请求和响应的处理逻辑。

三 单次过滤器

3.1 OncePerRequestFilter

OncePerRequestFilter 是 Spring 框架提供的一个过滤器基类，它继承自 Filter 接口。这个过滤器具有以下特点：

3.2 OncePerRequestFilter 使用场景

通过使用 OncePerRequestFilter，开发者可以确保过滤器逻辑在一次请求的生命周期内只执行一次，从而避免重复处理和潜在的性能问题。这使得 OncePerRequestFilter 成为处理复杂请求和响应逻辑时的一个非常有用的工具。

OncePerRequestFilter 的具体用法松哥就不举例了，第二小节已经介绍过了。

四 AOP 三件套

在 Spring 框架中，AOP（面向切面编程）是一个强大的功能，它允许开发者在不修改源代码的情况下，对程序的特定部分进行横向切入。AopContext、AopUtils 和 ReflectionUtils 是 Spring AOP 中提供的几个实用类。

我们一起来看下。

4.1 AopContext

AopContext 是 Spring 框架中的一个类，它提供了对当前 AOP 代理对象的访问，以及对目标对象的引用。

AopContext 主要用于获取当前代理对象的相关信息，以及在 AOP 代理中进行一些特定的操作。

常见方法有两个：

• getTargetObject(): 获取当前代理的目标对象。


• currentProxy(): 获取当前的代理对象。

其中第二个方法，在防止同一个类中注解失效的时候，可以通过该方法获取当前类的代理对象。

举个栗子：

public void noTransactionTask(String keyword){    // 注意这里 调用了代理类的方法

    ((YourClass) AopContext.currentProxy()).transactionTask(keyword);

}



@Transactional

void transactionTask(String keyword) {

    try {

        Thread.sleep(5000);

    } catch (InterruptedException e) {        //logger

        //error tracking

    }

    System.out.println(keyword);

}

同一个类中两个方法，noTransactionTask 方法调用 transactionTask 方法，为了使事务注解不失效，就可以使用 AopContext.currentProxy() 去获取当前代理对象。

4.2 AopUtils

AopUtils 提供了一些静态方法来处理与 AOP 相关的操作，如获取代理对象、获取目标对象、判断代理类型等。

常见方法有三个：

• getTargetObject(): 从代理对象中获取目标对象。


• isJdkDynamicProxy(Object obj): 判断是否是 JDK 动态代理。


• isCglibProxy(Object obj): 判断是否是 CGLIB 代理。

举个栗子：

import org.springframework.aop.framework.AopProxyUtils;

import org.springframework.aop.support.AopUtils;



public class AopUtilsExample {

    public static void main(String[] args) {

        MyService myService = ...

        // 假设 myService 已经被代理

        if (AopUtils.isCglibProxy(myService)) {

            System.out.println("这是一个 CGLIB 代理对象");

        }

    }

}

4.3 ReflectionUtils

ReflectionUtils 提供了一系列反射操作的便捷方法，如设置字段值、获取字段值、调用方法等。这些方法封装了 Java 反射 API 的复杂性，使得反射操作更加简单和安全。

常见方法：

• makeAccessible(Field field): 使私有字段可访问。


• getField(Field field, Object target): 获取对象的字段值。


• invokeMethod(Method method, Object target, Object... args): 调用对象的方法。

举个栗子：

import org.springframework.util.ReflectionUtils;



import java.lang.reflect.Field;

import java.util.Map;



public class ReflectionUtilsExample {

    public static void main(String[] args) throws Exception {

        ExampleBean bean = new ExampleBean();

        bean.setMapAttribute(new HashMap<>());



        Field field = ReflectionUtils.findField(ExampleBean.class, "mapAttribute");

        ReflectionUtils.makeAccessible(field);



        Object value = ReflectionUtils.getField(field, bean);

        System.out.println(value);

    }



    static class ExampleBean {

        private Map<String, String> mapAttribute;



        public void setMapAttribute(Map<String, String> mapAttribute) {

            this.mapAttribute = mapAttribute;

        }

    }

}

还有哪些实用内置类呢？欢迎小伙伴们留言～

首先感谢
Vue3 封装不定高虚拟列表 hooks，复用性更好！这篇文章提供的一些思路，在此基础作者进一步对相关代码进行了一些性能上的优化（解决了通过鼠标操作滚动条时的卡顿）。因为项目没有用到ts，就先去掉了。

hooks

import { ref, onMounted, onBeforeUnmount, watch, nextTick } from "vue";



export default function useVirtualList(config) {

  // 获取元素

  let actualHeightContainerEl = null,

    translateContainerEl = null,

    scrollContainerEl = null;

  // 数据源，便于后续直接访问

  let dataSource = [];



  onMounted(() => {

    actualHeightContainerEl = document.querySelector(

      config.actualHeightContainer

    );

    scrollContainerEl = document.querySelector(config.scrollContainer);

    translateContainerEl = document.querySelector(config.translateContainer);

  });



  // 数据源发生变动

  watch(

    () => config.data.value,

    (newValue) => {

      // 更新数据源

      dataSource = newValue;

      // 计算需要渲染的数据

      updateRenderData();

    }

  );



  /* 

  

  

  

    更新相关逻辑

  

  

  

  */

  // 更新实际高度

  let flag = false;

  const updateActualHeight = (oldValue, value) => {

    let actualHeight = 0;

    if (flag) {

      // 修复偏差

      actualHeight =

        actualHeightContainerEl.offsetHeight -

        (oldValue || config.itemHeight) +

        value;

    } else {

      // 首次渲染

      flag = true;

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

        actualHeight += getItemHeightFromCache(i);

      }

    }

    actualHeightContainerEl.style.height = `${actualHeight}px`;

  };



  // 缓存已渲染元素的高度

  const RenderedItemsCache = {};

  const RenderedItemsCacheProxy = new Proxy(RenderedItemsCache, {

    get(target, key, receiver) {

      return Reflect.get(target, key, receiver);

    },

    set(target, key, value, receiver) {

      const oldValue = target[key];

      const result = Reflect.set(target, key, value, receiver);

      // 更新实际高度

      updateActualHeight(oldValue, value);

      return result;

    },

  });



  // 更新已渲染列表项的缓存高度

  const updateRenderedItemCache = (index) => {

    // 当所有元素的实际高度更新完毕，就不需要重新计算高度

    const shouldUpdate =

      Reflect.ownKeys(RenderedItemsCacheProxy).length < dataSource.length;

    if (!shouldUpdate) return;



    nextTick(() => {

      // 获取所有列表项元素(size条数)

      const Items = Array.from(document.querySelectorAll(config.itemContainer));

      // 进行缓存（通过下标作为key)

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

        const el = Reflect.get(Items, i);

        const itemIndex = index + i;

        if (!Reflect.get(RenderedItemsCacheProxy, itemIndex)) {

          Reflect.set(RenderedItemsCacheProxy, itemIndex, el.offsetHeight);

        }

      }

    });

  };



  // 获取缓存高度，无缓存，取配置项的 itemHeight

  const getItemHeightFromCache = (index) => {

    const val = Reflect.get(RenderedItemsCacheProxy, index);

    return val === void 0 ? config.itemHeight : val;

  };



  // 实际渲染的数据

  const actualRenderData = ref([]);



  // 更新实际渲染数据

  const updateRenderData = (scrollTop = 0) => {

    let startIndex = 0;

    let offsetHeight = 0;



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

      offsetHeight += getItemHeightFromCache(i);



      // 第几个以上进行隐藏

      if (offsetHeight >= scrollTop - (config.offset || 0)) {

        startIndex = i;

        break;

      }

    }

    // 计算得出的渲染数据

    actualRenderData.value = dataSource

      .slice(startIndex, startIndex + config.size)

      .map((data, idx) => {

        return {

          key: startIndex + idx + 1, // 为了在vue的for循环中绑定唯一key值

          data,

        };

      });



    // 缓存最新的列表项高度

    updateRenderedItemCache(startIndex);



    updateOffset(offsetHeight - getItemHeightFromCache(startIndex));

  };



  // 更新偏移值

  const updateOffset = (offset) => {

    translateContainerEl.style.transform = `translateY(${offset}px)`;

  };



  /* 

  

  

  

    注册事件、销毁事件

  

  

  

  */

  // 滚动事件

  const handleScroll = (e) =>

    // 渲染正确的数据

    updateRenderData(e.target.scrollTop);



  // 注册滚动事件

  onMounted(() => {

    scrollContainerEl?.addEventListener("scroll", handleScroll);

  });



  // 移除滚动事件

  onBeforeUnmount(() => {

    scrollContainerEl?.removeEventListener("scroll", handleScroll);

  });



  return { actualRenderData };

}

vue

<script setup>

import { ref } from "vue";

import useVirtualList from "../utils/useVirtualList.js"; // 上面封装的hooks文件

import list from "../json/index.js"; // 造的数据模拟

const tableData = ref([]);

// 模拟异步请求

setTimeout(() => {

  tableData.value = list;

}, 0);

const { actualRenderData } = useVirtualList({

  data: tableData, // 列表项数据

  scrollContainer: ".scroll-container", // 滚动容器

  actualHeightContainer: ".actual-height-container", // 渲染实际高度的容器

  translateContainer: ".translate-container", // 需要偏移的目标元素,

  itemContainer: ".item", // 列表项

  itemHeight: 400, // 列表项的大致高度

  size: 10, // 单次渲染数量

  offset: 200, // 偏移量

});

</script>



<template>

  <div>

    <h2>virtualList 不固定高度虚拟列表</h2>

    <ul class="scroll-container">

      <div class="actual-height-container">

        <div class="translate-container">

          <li

            v-for="item in actualRenderData"

            :key="item.key"

            class="item"

            :class="[{ 'is-odd': item.key % 2 }]"

          >

            <div class="item-title">第{{ item.key }}条：</div>

            <div>{{ item.data }}</div>

          </li>

        </div>

      </div>

    </ul>

  </div>

</template>



<style scoped>

* {

  list-style: none;

  padding: 0;

  margin: 0;

}

.scroll-container {

  border: 1px solid #000;

  width: 1000px;

  height: 200px;

  overflow: auto;

}

.item {

  border: 1px solid #ccc;

  padding: 20px;

  display: flex;

  flex-wrap: wrap;

  word-break: break-all;

}

.item.is-odd {

  background-color: rgba(0, 0, 0, 0.1);

}

</style>

大家好，我是徐徐。今天和大家谈谈我做 Electron 桌面端应用的这一两年，把一些经验和想法分享给大家。

前言

入职现在这家公司三年了，刚进公司的时候是 21 年年初，那时候会做一些稍微复杂的后台管理系统以及一些简单的 C 端 SDK。准备开始做 Electron 项目是因为我所在的是安全部门，急需一款桌面管控软件来管理（监控）员工的电脑安全以及入网准入，可以理解为一款零信任的桌面软件。其实之前公司也有一款安全管控的软件，但是Windows 和 Mac是分端构建的，而且维护成本极高，Windows 是使用的 C#, Mac 是用的 Objective-C，开发和发版效率低下，最后在研发老大的同意下，我和另外一个同事开始研究如何用 Electron 这个框架来做一款桌面端软件。

我们发起这个项目大概是在 21 年年底，Windows 版本上线是在上海疫情封城期间，2022年4月份的时候，疫情结束后由于事业部业务方向的调整，又被抽调到了另外一个组去做一个 C 端的创业项目，后面项目结束了，又回来做 Electron 相关的工作直到现在，之所以是一两年，其实就是这个时间线。

对桌面端开发的一些看法

如果你是前端的话，多一门桌面端开发的技能也不是坏事，相当是你的一个亮点，进可攻，退可守。因为桌面端开发到后期的架构可以非常的复杂，不亚于服务端（chromium 就是一个例子），当然也取决于你所应对的场景的挑战，如果所做的产品跟普通前端无异，那也不能说是一个亮点，但是如果你的工作已经触及到一些操作系统的底层，那肯定是一个亮点。

当然也有人说，做桌面端可能就路越走越窄了，但是我想说的是深度和广度其实也可以理解为一个维度，对于技术人来说，知道得越多就行，因为到后期你要成为某个方面的专家，就是可能会非常深入某一块，换一种思路其实也是叫知道得越多。所以，我觉得前端能有做桌面端的机会也是非常好的，即拓展了自己的技能，还能深入底层，因为现阶段由于业务方向的需要，我已经开始看 chromium 源码了，前端的老祖宗。当然，以上这些只代表自己的观点，大家自行斟酌。

谈谈 Electron

其实刚刚工作前两年我就知道这个框架了，当时也做过小 demo，而且还在当时的团队里面分享过这个技术，但是当时对这门技术的认知是非常浅薄的，就知道前端可以做桌面端了，好厉害，大概就停留在这个层面。后面在真正需要用到这门技术去做一个企业级的桌面应用的时候才去真正调研了一下这个框架，然后才发现它真的非常强大，强大到几乎可以实现你桌面端的任何需求。网上关于 Electron 与其他框架的对比实在是太多了，Google 或者 Baidu 都能找到你想要的答案，好与不好完全看自己的业务场景以及自己所在团队的情况。

谈谈自己的感受，什么情况下可以用这门框架

• 追求效率，节省人力财力


• 团队前端居多


• UI交互多

什么情况下不适合这门框架呢？

• 包体积限制


• 性能消耗较高的应用


• 多窗口应用

我们当时的情况就是要追求效率，双端齐头并进，所以最后经过综合对比，选择了 Electron。毕竟 Vscode 就是用它做的，给了我们十足的信心和勇气，一点都不虚。

一图抵千字，我拿出这张图你自己就有所判断了，还是那句话，仁者见仁，智者见智，完全看自己情况。

图片来源：http://www.electronjs.org/apps

技术整体架构

这里我画了一张我所从事 Electron 产品的整体技术架构图。

整个项目基于 Vite 开发构建的，基础设施就是常见的安全策略，然后加上一些本地存储方案，外加一个外部插件，这个插件是用 Tauri 做的 Webview，至于为什么要做这个插件我会在后面的段落说明。应用层面的框架主要是分三个大块，下面主要是为了构建一些基础底座，然后将架构进行分层设计，添加一些原生扩展，上面就是基础的应用管理和 GUI 相关的东西，有了这个整体的框架在后面实现一些业务场景的时候就会变得易如反掌（夸张了一点，因为有的技术细节真的很磨人😐）。

当然这里只是一个整体的架构图，其实还有很多技术细节的流程图以及业务场景图并没有在这里体现出来，不过我也会挑选一些方案在后面的篇幅里面做出相应的讲解。

挑战和方案

桌面端开发会遇到一些挑战，这些挑战大部分来源于特殊的业务场景，框架只能解决一些比较常见的应用场景，当然不仅仅是桌面端，其实移动端或者是 Web 端我相信大家都会遇到或多或少的挑战，我这里遇到的一些挑战和响应的方案不一定适合你，只是做单纯的记录分享，如果有帮助到你，我很开心。下面我挑选软件升级更新，任务队列设计，性能检测优化以及一些特殊的需求这几个方面来聊聊相应的挑战和方案。

软件升级更新

桌面端的软件更新升级是桌面端开发中非常重要的一环，一个好的商业产品必须有稳定好用的解决方案。桌面端的升级跟 C 端 App 的升级其实也是差不多的思路，虽然我所做的产品是公司内部人使用，但是用户也是你面向公司所有用户的，所以跟 C 端产品的解决思路其实是无异的。

升级更新主要是需要做到定向灰度。这个功能是非常重要的，应该大部分的应用都有定向灰度的功能，所以我们为了让软件能够平滑升级，第一步就是实现定向灰度，达到效果可回收，性能可监控，错误可告警的目的。定向更新的功能实现了之后，后面有再多的功能需要实现都有基础保障了，下面是更新相关的能力图。

整个更新模块的设计是分为两大块，一块是后台管理系统，一块是客户端。后台管理系统主要是维护相应的策略配置，比如哪些设备需要定向更新，哪些需要自动更新，不需要更新的白名单以及更新后是需要提醒用户相应的更新功能还是就静默更新。客户端主要就是拉取相应的策略，然后执行相应的更新动作。

由于我们的软件是比较特殊的一个产品，他是需要长期保活的，Mac 端上了文件锁是无法删除的。所以我们在执行更新的时候和常规的软件更新是不一样的，软件的更新下载是利用了 electron-update 相应的钩子，但是安装的时候并没有使用相应的钩子函数，而是自己研究了 electron 的更新源码后做了自己的更新脚本。 因为electron 的更新它自己也会注册一个保活的更新任务的服务，但是这个和我们的文件锁和保活是冲突的，所以是需要禁用掉它的保活服务，完成自己的更新。

整体来说，这一块是花了很多时间去研究的，windows 还好，没有破坏其整个生命周期，傻瓜式的配置一下electron-update 相关的函数钩子就可以了。Mac 的更新花了很多时间，因为破坏了文件的生命周期，再加上保活任务，所以会对 electron-update 的更新钩子进行毁灭性的破坏，最后也只能研究其源码然后自己去实现特殊场景下的更新了。

任务队列设计

任务模块的实现在我们这个软件里面也是非常重要的一环，因为客户端会跑非常多的定时任务。刚开始研发这个产品的时候其实还好，定时任务屈指可数，但是随着长时间的迭代，端上要执行的任务越来越多，每个任务的触发时间，触发条件都不一样，以及还要考虑任务的并发情况和对性能的影响，所以在中后期我们对整个任务模块都做了相应的改造。

下面是整个任务模块的核心能力图。

业界也有一些任务相关的开源工具包，比如 node-schedule、node-cron、cron，这些都是很优秀的库，但是我在使用过程中发现他们好像不具备并发限制的场景，比如有很多任务我们在开始设置的时候都会有个时间间隔，这些任务的时间间隔都是可以在后台随意配置的，如果端上不做并发限制会导致一个问题，就是用户某一瞬间会觉得电脑非常卡。

比如你有 4 个 10 分钟间隔的任务 和 2 个五分钟间隔的任务，那么到某一个时间段，他最大并发可能就是 6，如果刚好这 6 个任务都是非常耗费 CPU 的任务，那他们一起执行的时候就会导致整个终端CPU 飙升，导致用户感觉卡顿，这样就会收到相应的 Diss。

安全类的软件产品其实有的时候不需要太过醒目，后台默默运行就行，所以我们的宗旨就是稳定运行，不超载。为此我们就自己实现了相应的任务队列模式，然后去控制任务并发。其实底层逻辑也不难，就是一个 setInterval 的函数，然后不断的创建销毁，读取队列的函数，执行相应的函数。

性能优化

Electron相关的性能优化其实网上也有非常多的文章，我这里说说我的实践和感受。

首先，性能优化你需要优化什么？这个就是你的出发点了，我们要解决一个问题，首先得知道问题的现状，如果你都不知道现在的性能是什么样子，如何去优化呢？所以发现问题是性能优化的最重要的一步。

这里就推荐两个工具，一个是chrome dev-tool，一个是electron 的 inspector，第一个可以观测渲染进程相关的性能情况，第二个可以观测主进程相关的性能情况。

具体可参考以下网址：

• developer.chrome.com/docs/devtoo…


• http://www.electronjs.org/zh/docs/lat…

有了工具之后我们就需要用工具去分析一些数据和问题，这里面最重要的就是内存相关的分析，你通过内存相关的分析可以看到 CPU 占用高的动作，以及提前检测出内存泄漏的风险。只要把这两个关键的东西抓住了，应用的稳定性就可以得到保障了，我的经验就是每次发布之前都会跑一遍内存快照，内存没有异常才进行发布动作，内存泄漏是最后的底线。

我说说我大概的操作步骤。

• 通过Performance确认大体的溢出位置


• 使用Memory进行细粒度的问题分析


• 根据heap snapshot，判断内存溢出的代码位置


• 调试相应的代码块


• 循环往复上面的步骤

上面的步骤在主进程和渲染进程都适用，每一步实际操作在这里就不详细展开了，主要是提供一个思路和方法，因为 dev-tool 的面板东西非常多，扩展开来都可以当一个专题了。

然后我再说说桌面端什么地方可能会内存泄漏或者溢出，下面这些都是我血和泪的教训。

• 创建的子进程没有及时销毁：

如果子进程在完成任务后未被正确终止，这些进程会继续运行并占用系统资源，导致内存泄漏和资源浪费。

假设你的 Electron 应用启动了一个子进程来执行某些计算任务，但在计算完成后未调用
childProcess.kill() 或者未确保子进程已正常退出，那么这些子进程会一直存在，占用系统内存。

const { spawn } = require('child_process');

const child = spawn('someCommand');



child.on('exit', () => {

    console.log('Child process exited');

});



// 未正确终止子进程可能导致内存泄漏

• HTTP 请求时间过长没有正确处理：

长时间未响应的 HTTP 请求如果没有设定超时机制，会使得这些请求占用内存资源，导致内存泄漏。

在使用 fetch 或 axios 进行 HTTP 请求时，如果服务器长时间不响应且没有设置超时处理，内存会被这些未完成的请求占用。

const fetch = require('node-fetch');



fetch('https://example.com/long-request')

    .then(response => response.json())

    .catch(error => console.error('Error:', error));



// 应该设置请求超时

const controller = new AbortController();

const timeout = setTimeout(() => {

    controller.abort();

}, 5000); // 5秒超时



fetch('https://example.com/long-request', { signal: controller.signal })

    .then(response => response.json())

    .catch(error => console.error('Error:', error));

• 事件处理器没有移除

未正确移除不再需要的事件处理器会导致内存一直被占用，因为这些处理器仍然存在并监听事件。

在添加事件监听器后，未在适当时机移除它们会导致内存泄漏。

const handleEvent = () => {

    console.log('Event triggered');

};



window.addEventListener('resize', handleEvent);



// 在不再需要时移除事件监听器

window.removeEventListener('resize', handleEvent);

• 定时任务未被正确销毁

未在适当时候清除不再需要的定时任务（如 setInterval）会导致内存持续占用。

使用 setInterval 创建的定时任务，如果未在不需要时清除，会导致内存泄漏。

const intervalId = setInterval(() => {

    console.log('Interval task running');

}, 1000);



// 在适当时机清除定时任务

clearInterval(intervalId);

• JavaScript 对象未正确释放

长时间保留不再使用的 JavaScript 对象会导致内存占用无法释放，特别是当这些对象被全局变量或闭包引用时。

创建了大量对象但未在适当时机将它们置为 null 或解除引用。

let bigArray = new Array(1000000).fill('data');



// 当不再需要时，应释放内存

bigArray = null;

• 窗口实例未被正确销毁

未关闭或销毁不再使用的窗口实例会继续占用内存资源，即使用户已经关闭了窗口界面。

创建了一个新的 BrowserWindow 实例，但在窗口关闭后未销毁它。

const { BrowserWindow } = require('electron');

let win = new BrowserWindow({ width: 800, height: 600 });



win.on('closed', () => {

    win = null;

});



// 应确保在窗口关闭时正确释放资源

• 大文件或大数据量的处理

处理大文件或大量数据时，如果没有进行内存优化和分批处理，会导致内存溢出和性能问题。

在读取一个大文件时，未采用流式处理，而是一次性加载整个文件到内存中。

const fs = require('fs');



// 不推荐的方式：一次性读取大文件

fs.readFile('largeFile.txt', (err, data) => {

    if (err) throw err;

    console.log(data);

});



// 推荐的方式：流式读取大文件

const readStream = fs.createReadStream('largeFile.txt');

readStream.on('data', (chunk) => {

    console.log(chunk);

});

一些特殊的需求

做这个产品也遇到一些特殊的需求，有的需求还挺磨人的，这里也和大家分享一下。

• 保活和文件锁

作为一个前端，桌面端的保活和文件锁这种需求基本是之前不可能接触到的，为了做这个需求也去了解了一下业界的实现，其实实现都还好，主要是它会带来一些问题，诸如打包构建需要自定义前置脚本和后置脚本，root 用户环境下 mac 端无法输入中文，上面提到的用 Tauri 构建一个 webview 组件就是为了解决 root 用户无法输入中文的场景。

• 静默安装应用

这个需求也是很绝的一个需求。我想如果是做常规的前端开发，估计一般都不会遇到这种需求，你需要从头到尾实现一个下载器，一个软件安装器，而且还要双端适配，不仅如此，还需要实现 exe、zip、dmg、pkg 等各种软件格式的安装，里面包含重试机制，断点下载，队列下载等各种技术细节。当时接到这个需求头也特别大，不过技术方案做出来后感觉也还好，再复杂的需求只要能理清思路，其实都可以慢慢解决。

• VPN 和 访问记录监控

这种需求对一个前端来说更是无从入手，但是好在之前有老版本的 VPN 做参考，就是根据相应的代码翻译一遍也能实现，大部分可以用命令行解决。至于访问记录监控这个玩意咋说呢，客户端做其实也挺费神的，如果不借助第三方的开源框架，自己是非常难实现的，所以这种就是需要疯狂的翻国外的网站，就GitHub，Stackoverflow啰，总有一款适合你，这里就不具体说明了。

• 进程禁用

违规进程禁用其实在安全软件的应用场景是非常常见的，它需要实时性，而且对性能要求很高，一个是不能影响用户正常使用，还要精准杀掉后台配置的违规进程，这个地方其实也是做了很多版优化，但是最后的感觉还是觉得任务队列有性能瓶颈，无法达到要求，现阶段我们也在想用另外的方式去改造，要么就是上全局钩子，要么就是直接把相应的进程文件上锁或者改文件权限。

上面所提到的需求只是一小部例子，还好很多奇奇怪怪的需求没有举例，这些奇怪的需求就像小怪物，不断挑战我的边界，让我也了解和学习和很多奇奇怪怪的知识，有的时候我就会发出这样的感叹：我去，还能这样？

结语

洋洋洒洒，不知不觉已经写了 5000 字了，其实做 Electron 桌面端应用的这一两年自我感觉还是成长了不少，不管是技术方面还是产品设计方面，自己的能力都有所提升。但是同样会遇到瓶颈，就是一个东西一直做一直做，到后面创新会比较难，取得的成就也会慢慢变少。

另外就是安全类的桌面端产品在整个软件开发的里其实是非常冷门的一个领域，他有他的独特性，也有相应的价值，他需要默默的运行，稳定的运行，出问题可以监控到，该提醒的时候提醒用户。你说他低调吧，有时候也挺高调的，真的不好定论，你说没影响力吧，有的时候没他还真不行。让用户不反感这种软件，拥抱这种软件其实挺难的。从一个前端开发的视角来看，桌面端的体验的确很重要，不管是流畅度还是美观度，都不能太差，这也是我们现阶段追求的一个点，就是不断提升用户体验。

路漫漫其修远兮，吾将上下而求索。前端开发这条路的确很长，如果你想朝某个方面深度发展，你会发现边界是非常难触达的，当然也看所处的环境和对应的机遇，就从技术来说的话，前端的天花板也可以很高，不管是桌面端，服务端，移动端，Web端，每个方向前端的天花板都非常难触摸到。

最后，祝大家在自己的领域越来越深，早日触摸到天花板。

原文链接

mp.weixin.qq.com/s/SzN8wvqxj…

互联网时代，程序员承担着数字世界构建和技术发展的大任，如此重要，为什么存在感不高，社会地位不高呢？

知乎上针对这个问题也有过讨论，分享给大家。

http://www.zhihu.com/question/58…

回答1

什么是社会地位？

社会地位可以简化成，一个人可支配社会资源的数量，例如：

医生 医疗资源

教师 教育资源

...

而程序员可支配的社会资源只有他自己。从这一点上说，程序员和工人没有本质上的区别。

时代的红利成就了这个职业，抛弃它的时候，一样不会留情。

回答2

程序员作为一种社会职业，既没有政府职能部门的公权力，又没有有钱人的一掷千金，挣得也都是辛苦钱，何来社会地位高不高一说，无非就是资本的韭菜罢了。

回答3

这个问题我曾经思考过很久。按知乎的习惯，先问是不是，再问为什么。

首先说“是不是”。

按大家的直觉也好，或者现有的各个社区讨论来看，程序员的社会地位肯定不是高的。

最多有人说程序员的社会地位和其他职业一样高，但没见过谁说程序员的社会地位能高过GWY，医生，老师的。这么说来，“是不是”这个问题已经基本没有大的争议——在公众认知内，程序员的社会地位的确不高。

再来就是“为什么”。

这个为什么是我想了很久了，如果单独拿程序员和某个职业/行业比较，可以有很多个维度的对比，但如果想把大部分的职业/行业进行对比，需要找一个更有共性的比较方式，或者说是能归纳出比较重要的影响因素。对此，我归纳出来的最主要因素是“自由裁量权”。

这里的“自由裁量权”，又分为两个维度：

第一个是权力本身影响后果的大小，比如影响10块钱和影响10亿元的大小肯定不一样；

第二个是权力影响的范围，比如影响一个区和影响全国肯定不一样。

这里举电视剧《人民的名义》里面的人物来说明这一点。

第一个剧中是京州市副市长兼光明区区委书记丁义珍。丁义珍是“负责土地划批，矿产资源整合，还有老城改造”，这里无论是土地划批给某开发商，或者矿产资源交给哪个煤老板开挖，对于这些开发商和煤老板，都一笔稳赚不赔的买卖。而剧中的丁义珍在具体能把这块地或者这片矿批给谁上面，有很大的自由裁量权，也就是说，他能在规则范围之内，把地给批了。于是各个房地产开发商老板，煤矿老板都要找丁义珍去批地批矿，自然丁义珍社会地位就高了。

第二个是京州市城市银行副行长欧阳菁。作为银行副行长，很多带款她拥有最终决定权。是放贷或者不放贷，放贷放给哪个企业，她拥有决定权力，甚至还能影响汉东农信社的决定。比如在蔡成功申请六千万的带款的事情上，欧阳菁一直阻挠，甚至打电话让汉东农信社不给蔡成功带款。为什么以前能贷给蔡成功，而这次不行了呢，那是因为之前每次过桥贷蔡成功都给欧阳菁50万好处费，而这次没有。

从以上两个例子可以出，无论是在ZF，还是银行这种企业里，当官至一定地位时，就拥有了影响社会面的一定量的自由裁量权。无论是丁义珍还是欧阳菁，他们的自由裁量权总体上还是在规则之内运行的，没有明显超出规则之外。要不是赵德汉被查，丁义珍还没那么快会被抓以至于后面要逃亡国外。而欧阳菁如果不是因为侯亮平下来查山水集团等案子，也不会露出马脚。

在最开始说了，自由裁量权除了影响的后果大小，还有涉及面的大小，比如丁义珍和欧阳菁的影响力，主要还是在京州市之内，出了京州市，尤其是出了汉东省，他们也影响不到啥。而剧中的第一个出场的贪官赵德汉，就有影响全国资源项目的审核权，这就是影响面的区别了。所以才有那个全国各地都有人找赵德汉，在他办公室门口排队的事情了。

通过《人民的名义》这三个例子，自由裁量权的影响力和影响面应该都有一定的了解了。

那么我们回过头来看现实中的程序员，这个职业带来的对于社会影响的自由裁量权，可以看出是非常小的，影响面也非常不适合操作。

首先，程序员可以决定程序的技术架构和代码，但很难影响其功能。真正决定功能是怎么样的，是产品经理（网站、APP类）、策划（游戏类）、甲方（to B和to G类），程序员本身几乎没有话语权，即没有自由裁量权，更多地是执行权。即使程序员做到了manager，或者技术VP，甚至CTO，对于这些功能特性的影响都是有限的。

比如说你是某游戏的技术leader，过年了你侄子在玩这款游戏，他希望你帮他的角色属性全部乘以10，你也是做不到的，甚至在内部评审阶段都被砍了。从影响面的角度来看，如果程序员是做某个APP的，他没法影响同公司另一款APP怎么做，更别说影响别的公司的APP怎么做。用通俗点的话来说，无论是社会上的陌生人，还是亲戚朋友，希望找程序员去做一些其职业内能自由裁量的内容从而获益，是很难的。这也就是程序员社会不高的主要原因。

同理，按照这个框架，我们能分析其他的一些职业的社会地位，同时也能看到一些职业除了稳定之外，还有自由裁量权这一微妙的东西，让不少人甘愿去追逐。

全文完

或许，这些讨论，并不能改变现实。

我觉得我们要思考的是：

社会地位的标准到底是什么？

技术人如今的社会地位，合理不合理？

技术人做什么，能够改变自己的社会地位？

处理错误的两种方式：try...catch 与 then、catch

在前端编程中，错误和异常处理是保证代码健壮性和用户体验的重要环节。JavaScript 提供了多种方式来处理错误，其中最常见的两种是 try...catch 和 Promise 的 then、catch，但是什么时候该用try...catch，什么时候该用then、catch呢，下面将详细探讨这两种机制的区别及其适用场景。

一、try...catch

try...catch 是一种用于捕获和处理同步代码中异常的机制。其基本结构如下：

try {

    // 可能会抛出异常的代码

} catch (error) {

    // 处理异常

}

使用场景：

• 主要用于同步代码，尤其是在需要处理可能抛出的异常时。


• 适用于函数调用、操作对象、数组等传统代码中。

示例：

function divide(a, b) {

    try {

        if (b === 0) {

            throw new Error("Cannot divide by zero");

        }

        return a / b;

    } catch (error) {

        console.error(error.message);

    }

}



divide(4, 0); // 输出: Cannot divide by zero

在这个例子中，如果 b 为零，则会抛出一个错误，并被 catch 块捕获。

二、then 和 catch

在处理异步操作时，使用 Promise 的 then 和 catch 方法是更加常见的做法。其结构如下：

someAsyncFunction()

    .then(result => {

        // 处理成功的结果

    })

    .catch(error => {

        // 处理错误

    });

使用场景：

• 主要用于处理异步操作，例如网络请求、文件读取等。


• 可以串联多个 Promise 操作，清晰地处理成功和错误。

示例：

function fetchData() {

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

        // 模拟异步操作

        setTimeout(() => {

            const success = Math.random() > 0.5; // 随机决定成功或失败

            if (success) {

                resolve("Data fetched successfully");

            } else {

                reject("Failed to fetch data");

            }

        }, 1000);

    });

}



fetchData()

    .then(result => {

        console.log(result);

    })

    .catch(error => {

        console.error(error);

    });

在这个示例中，fetchData 函数模拟了一个异步操作，通过 Promise 来处理结果和错误。

三、async/await 与 try...catch

为了使异步代码更具可读性，JavaScript 引入了 async/await 语法。结合 try...catch，可以让异步错误处理更加简洁：

async function fetchDataWithAwait() {

    try {

        const result = await fetchData();

        console.log(result);

    } catch (error) {

        console.error(error);

    }

}



fetchDataWithAwait();

总结

• try...catch：适合于同步代码，能够捕获代码块中抛出的异常。


• then 和 catch：用于处理 Promise 的结果和错误，适合异步操作。


• async/await 结合 try...catch：提供了清晰的异步错误处理方式，增强了代码的可读性。

在实际开发中，选择哪种方式取决于代码的性质（同步或异步）以及个人或团队的编码风格。

往期推荐

前端如何实现图片伪防盗链，保护页面图片🔥

适当使用$forceUpdate()🔥

怎么进行跨组件通信，教你如何使用provide 和 inject🔥

使用reactive导致数据失去响应式？🔥

前言

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

URL.createObjectURL()

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

1. 语法

let objectURL = URL.createObjectURL(object);

2. 参数

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

3. 返回值

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

4. 示例

"file" id="file">



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

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

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

}

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

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

URL.revokeObjectURL()

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

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

1. 语法

window.URL.revokeObjectURL(objectURL);

2. 参数 objectURL

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

3. 返回值

undefined

4. 示例

"file" id="file">

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

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



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

	const file = e.target.files[0]

	

	const URL1 = URL.createObjectURL(file)

	console.log(URL1)

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

	URL.revokeObjectURL(URL1)

	

	const URL2 = URL.createObjectURL(file)

	console.log(URL2)

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

}

与FileReader.readAsDataURL(file)区别

1. 主要区别

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


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

2. 执行时机

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


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

3. 内存使用

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


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

4. 优劣对比

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


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

常见的大屏数据请求方式

1、http请求轮询：使用定时器每隔多少时间去请求一次数据。优点：简单，传参方便。缺点：数据更新不实时，浪费服务器资源（一直请求，但是数据并不更新）

2、websocket：使用websocket实现和服务器长连接，服务器向客户端推送大屏数据。优点：长连接，客户端不用主动去请求数据，节约服务器资源（不会一直去请求数据，也不会一直去查数据库），数据更新及时，浏览器兼容较好（web、h5、小程序一般都支持）。缺点：有点大材小用，一般大屏数据只需要查询数据不需要向服务端发送消息，还要处理心跳、重连等问题。

3、sse：基于http协议，将一次性返回数据包改为流式返回数据。优点：sse使用http协议，兼容较好、sse轻量，使用简单、sse默认支持断线重连、支持自定义响应事件。缺点：浏览器原生的EventSource不支持设置请求头，需要使用第三方包去实现（event-source-polyfill）、需要后端设置接口的响应头Content-Type: text/event-stream

sse和websocket的区别

Websocket和SSE分别适用于什么业务场景？

根据sse的特点（轻量、简单、单向通信）更适用于大屏的数据查询，业务应用上查询全局的一些数据，比如消息通知、未读消息等。

根据websocket的特点（双向通信）更适用于聊天功能的开发

前端代码实现

sse的前端的代码非常简单

 const initSse = () => {

        const source = new EventSource(`/api/wisdom/terminal/stats/change/notify/test`);



        // 这里的stats_change要和后端返回的数据结构里的event要一致

        source.addEventListener('stats_change', function (event: any) {

            const types = JSON.parse(event.data).types;

        });

        // 如果event返回的是message 数据监听也可以这样监听

        // source.onmessage =function (event) {

        //  var data = event.data;

        // };



        // 下面这两个监听也可以写成addEventListener的形式

        source.onopen = function () {

            console.log('SSE 连接已打开');

        };



        // 处理连接错误

        source.onerror = function (error: any) {

            console.error('SSE 连接错误:', error);

        };

        setSseSource(source);

    };

    

// 关闭连接

sseSource.close();

这种原生的sse连接是不能设置请求头的，但是在业务上接口肯定是要鉴权需要传递token的，那么怎么办呢？ 我们可以使用event-source-polyfill这个库

 const source = new EventSourcePolyfill(`/api/wisdom/terminal/stats/change/notify/${companyId}`, {

            headers: {

                Authorization: sessionStorage.get(StorageKey.TOKEN) || storage.get(StorageKey.TOKEN),

                COMPANYID: storage.get(StorageKey.COMPANYID),

                COMPANYTYPE: 1,

                CT: 13

            }

        });

        

        //其它的事件监听和原生的是一样

后端代码实现

后端最关键的是设置将响应头的Content-Type设置为text/event-stream、Cache-Control设置为no-cache、Connection设置为keep-alive。每次发消息需要在消息体结尾用"/n/n"进行分割，一个消息体有多个字段每个字段的结尾用"/n"分割。

var http = require("http");



http.createServer(function (req, res) {

  var fileName = "." + req.url;



  if (fileName === "./stream") {

    res.writeHead(200, {

      "Content-Type":"text/event-stream",

      "Cache-Control":"no-cache",

      "Connection":"keep-alive",

      "Access-Control-Allow-Origin": '*',

    });

    res.write("retry: 10000\n");

    res.write("event: connecttime\n");

    res.write("data: " + (new Date()) + "\n\n");

    res.write("data: " + (new Date()) + "\n\n");



    interval = setInterval(function () {

      res.write("data: " + (new Date()) + "\n\n");

    }, 1000);



    req.connection.addListener("close", function () {

      clearInterval(interval);

    }, false);

  }

}).listen(8844, "127.0.0.1");

其它开发中遇到的问题

我在开发调试中用的是umi，期间遇到个问题就是sse连接上了但是在控制台一直没有返回消息，后端那边又是正常发出了的，灵异的是在后端把服务干掉的一瞬间可以看到控制台一下接到好多消息。我便怀疑是umi的代理有问题，然后我就去翻umi的文档，看到了下面的东西：

一顿操作之后正常

小学生万万没想到，做个加减乘除的口算练习题，都能被大学生、博士生、甚至是程序员大佬们暴打！

最近这款拥有 PK 功能的《小猿口算》App 火了，谁能想到，本来一个很简单的小学生答题 PK，竟然演变为了第四次忍界大战！

刚开始还是小学生友好 PK，后面突然涌入一波大学生来踢馆，被网友称为 “大学生炸鱼”；随着战况愈演愈烈，硕士生和博士生也加入了战场，直接把小学生学习软件玩成了电子竞技游戏，谁说大一就不是一年级了？这很符合当代大学生的精神状态。

然而，突然一股神秘力量出现，是程序员带着科技加入战场！ 自动答题一秒一道 ，让小学生彻底放弃，家长们也无可奈何，只能在 APP 下控诉严查外挂。

此时很多人还没有意识到，小学生口算 PK，已经演变为各大高校和程序员之间的算法学术交流竞赛！

各路大神连夜改进算法，排行榜上的数据也是越发离谱，甚至卷到了 0.1 秒一道题！

算法的演示效果，可以看我发的 B 站视频。

接口也是口，算法也是算，这话没毛病。

这时，官方不得不出手来保护小学生了，战况演变为官方和广大程序员的博弈。短短几天，GitHub 上开源的口算脚本就有好几页，程序员大神们还找到了多种秒速答题的方案。

官方刚搞了加密，程序员网友马上就成功解密，以至于 网传 官方不得不高价招募反爬算法工程师，我建议直接把这些开源大佬招进去算了。

实现方法

事情经过就是这样，我相信朋友们也很好奇秒答题目背后的实现原理吧，这里我以 GitHub 排名最高的几个脚本项目为例，分享 4 种实现方法。当然，为了给小学生更好的学习体验，这里我就不演示具体的操作方法了，反正很快也会被官方打压下去。

方法 1、OCR 识别 + 模拟操作

首先使用模拟器在电脑上运行 App，运用 Python 读取界面上特定位置的题目，然后运用 OCR 识别技术将题目图片识别为文本并输入给算法程序来答题，最后利用 Python 的 pyautogui 库来模拟人工点击和输入答案。

这种方法比较好理解，应用范围也最广，但缺点是识别效果有限，如果题目复杂一些，准确度就不好保证了。

详见开源仓库：github.com/ChaosJulien…

方法 2、抓包获取题目和答案

通过 Python 脚本抓取 App 的网络请求包，从中获取题目和答案，然后通过 ADB（Android Debug Bridge）模拟滑动操作来自动填写答案。然而，随着官方升级接口并加密数据，这种方法已经失效。

详见开源仓库：github.com/cr4n5/XiaoY…

方法 3、抓包 + 修改答案

这个方法非常暴力！首先通过抓包工具拦截口算 App 获取题目数据和答案的网络请求，然后修改请求体中的答案全部为 “1”，这样就可以通过 ADB 模拟操作，每次都输入 1 就能快速完成答题。 根据测试可以达到接近 0 秒的答题时间！

但是这个方法只对练习场有效，估计是练习场的答题逻辑比较简单，且没有像 PK 场那样的复杂校验。

详见开源仓库：github.com/cr4n5/XiaoY…

方法 4、修改 PK 场的 JavaScript 文件

这种方法就更暴力了！在 PK 场模式下，修改 App 内部的 JavaScript 文件来更改答题逻辑。通过分析 JavaScript 响应中的 isRight 函数，找到用于判定答案正确与否的逻辑，然后将其替换为 true，强制所有答案都判定为正确，然后疯狂点点点就行了。

详见开源仓库：github.com/cr4n5/XiaoY…

能这么做是因为 App 在开发时采用了混合 App 架构，一些功能是使用 WebView 来加载网页内容的。而且由于 PK 场答题逻辑是在前端进行验证，而非所有请求都发送到服务器进行校验，才能通过直接修改前端 JS 文件绕过题目验证。

官方反制

官方为了保护小学生学习的体验，也是煞费苦心。

首先加强了用户身份验证和管理，防止大学生炸鱼小学生；并且为了照顾大学生朋友，还开了个 “巅峰对决” 模式，让俺们也可以同实力竞技 PK。

我建议再增加一个程序员模式，也给爱玩算法的程序员一个竞技机会。

其实从技术的角度，要打击上述的答题脚本，并不难。比如检测 App 运行环境，发现是模拟器就限制答题；通过改变题目的显示方式来对抗 OCR 识别；通过随机展示部分 UI， 让脚本无法轻易通过硬编码的坐标点击正确的答案；还可以通过分析用户的答题速度和操作模式来识别脚本，比如答题速度快于 0.1 秒的用户，显然已经超越了人类的极限。

0.0 秒的这位朋友，是不是有点过分（强大）了？

但最关键的一点是，目前 App 的判题逻辑是在前端负责处理的，意味着题目答案的验证可以在本地进行，而不必与服务器通信，这就给了攻击者修改前端文件的机会。虽然官方通过接口加密和行为分析等手段加强了防御，但治标不治本，还是将判题逻辑转移到服务端，会更可靠。

当然，业务流程改起来哪有那么快呢？

不过现在的局面也不错，大学生朋友快乐了，程序员玩爽了，口算 App 流量赢麻了，可谓是皆大欢喜！

等等，好像有哪里不对。。。别再欺负我们的小学生啦！

一：前言

浏览器缓存与浏览器储存是不一样的，友友们不要混淆，关于浏览器储存，具体可以看这篇文章 : 一篇打通浏览器储存

这里大概介绍一下：

二：强缓存

强缓存是指浏览器在请求资源时，如果本地有符合条件的缓存，那么浏览器会直接使用缓存而不会向服务器发送新的请求。这可以通过设置 Cache-Control 或 Expires 响应头来实现。

2.1：Cache-Control 头详解

Cache-Control 是一个非常强大的HTTP头部字段，它包含多个指令，用以控制缓存的行为：

• max-age：指定从响应生成时间开始，该资源可被缓存的最大时间（秒数）。


• s-maxage：类似于 max-age，但仅对共享缓存（如代理服务器）有效。


• public：表明响应可以被任何缓存存储，即使响应通常是私有的。


• private：表明响应只能被单个用户缓存，不能被共享缓存存储。


• no-cache：强制缓存在使用前必须先验证资源是否仍然新鲜。


• no-store：禁止缓存该响应，每次请求都必须获取最新数据。


• must-revalidate：一旦资源过期，必须重新验证其有效性。

例如，通过设置 Cache-Control: max-age=86400，可以告诉浏览器这个资源可以在本地缓存24小时。在这段时间内，如果再次访问相同URL，浏览器将直接使用缓存中的副本，而不与服务器通信。

2.2：Expires 头

Expires 是一个较旧的头部字段，用于设定资源过期的具体日期和时间。尽管现在推荐使用 Cache-Control，但在某些情况下，Expires 仍然是有效的。Expires 的值是一个绝对的时间点，而不是相对时间。例如：

Expires: Wed, 09 Oct 2024 18:29:00 GMT

2.3：浏览器默认行为

当用户通过地址栏直接请求资源时，浏览器通常会自动添加 Cache-Control: no-cache 到请求头中。这意味着即使资源已经存在于缓存中，浏览器也会尝试重新验证资源新鲜度，以确保用户看到的是最新的内容。

三：协商缓存

协商缓存发生在资源的缓存条目已过期或设置了 no-cache 指令的情况下。这时，浏览器会向服务器发送请求，并携带上次请求时收到的一些信息，以便服务器决定是否返回完整响应或只是确认没有更新。

3.1：Last-Modified/If-Modified-Since

后端服务器可以为每个资源设置 Last-Modified 头部，表示资源最后修改的时间。当下一次请求同一资源时，浏览器会在请求头中加入 If-Modified-Since 字段，其值为上次接收到的 Last-Modified 值。服务器检查这个时间戳，如果资源自那以后没有改变，则返回304 Not Modified状态码，指示浏览器使用缓存中的版本。

3.2：ETag/If--Match

ETag 提供了一种更精确的方法来检测资源是否发生变化。它是基于文件内容计算出的一个唯一标识符。当客户端请求资源时，服务器会在响应头中提供一个 ETag 值。下次请求时，浏览器会发送 If--Match 头部，包含之前接收到的 ETag。如果资源未改变，服务器同样返回304状态码；如果有变化，则返回完整的资源及新的 ETag 值。

3.3：比较 Last-Modified 和 ETag

虽然 Last-Modified 简单易用，但它基于时间戳，可能会受到时钟同步问题的影响。相比之下，ETag 更加准确，因为它依赖于资源的实际内容。然而，ETag 计算可能需要更多的服务器处理能力。

四：缓存选择

合理的缓存策略能够显著提升网站性能和用户体验。例如，静态资源（如图片、CSS、JavaScript文件）适合设置较长的缓存时间，而动态内容则需谨慎对待，避免缓存不适当的信息。

• 使用工具如 Chrome DevTools 来分析页面加载时间和缓存效果。


• 对不同类型的资源设置合适的 Cache-Control 参数。


• 注意安全性和隐私保护，确保敏感数据不会被错误地缓存。

五：使用示例

server.js:

const http = require('http'); // 引入HTTP模块

const path = require('path'); // 引入路径处理模块

const fs = require('fs'); // 引入文件系统模块

const mime = require('mime'); // 引入MIME类型模块



// 创建一个HTTP服务器

const server = http.createServer((req, res) => {

  // console.log(req.url); // /index.html    //   /assets/image/logo.png

  

  // 根据请求的URL生成文件路径

  let filePath = path.resolve(__dirname, path.join('www', req.url));



  // 检查文件或目录是否存在

  if (fs.existsSync(filePath)) {

    const stats = fs.statSync(filePath); // 获取该路径对应的资源状态信息

    // console.log(stats);

    

    const isDir = stats.isDirectory(); // 判断是否是文件夹

    const { ext } = path.parse(filePath); // 获取文件扩展名

    if (isDir) {

      // 如果是目录，则指向该目录下的 index.html 文件

      filePath = path.join(filePath, 'index.html');

    }



    // +++++ 获取前端请求头中的if-modified-since

    const timeStamp = req.headers['if-modified-since']; // 获取请求头中的 If-Modified-Since 字段

    let status = 200; // 默认响应状态码为200

    if (timeStamp && Number(timeStamp) === stats.mtimeMs) { // 如果 If-Modified-Since 存在且与文件最后修改时间相同

      status = 304; // 设置响应状态码为304，表示资源未变更

    }



    // 如果不是目录且文件存在

    if (!isDir && fs.existsSync(filePath)) {

      const content = fs.readFileSync(filePath); // 读取文件内容

      res.writeHead(status, {

        'Content-type': mime.getType(ext), // 设置 Content-Type 头

        'cache-control': 'max-age=86400',  // 设置缓存控制为一天

        // 'last-modified': stats.mtimeMs,  // 资源最新修改时间（可选）

        // 'etag': '由文件内容生成的hash'  // 文件指纹（可选）

      });

      res.end(content); // 发送文件内容作为响应体

    } 

  }

  

});



// 启动服务器，监听3000端口

server.listen(3000, () => {

  console.log('listening on port 3000');

});r.listen(3000, () => {

  console.log('listening on port 3000');

});

index.html:

<body>

  <h1>midsummer</h1>

  <img src="assets/image/1.png" alt="">

</body>

项目结构如下图，友友们自行准备一张图片，将项目npm init -y 初始化为后端项目，之后下载mime@3包，在终端输入npx nodemon server.js运行起来，在浏览器中查看http://localhost:3000/index.html ，观察效果。在检查中的网络里看缓存效果，同时友友们可以更改图片或者缓存方式，体验下不同的浏览器缓存方式

ChatGPT这个轰动全球的产品自问世以来，已经过了将近2年的时间，各行各业的精英们如火如荼的将AI能力应用到自己生产的产品中来。

为分担人类的部分工作，AI还具有非常大的想象空间，例如对于一个程序员来说，使用AI生成快速生成自己的小程序，相信在AI能力与开发工具融合从可用性到易用性普及以后，会变成一个“习以为常”的操作。

App or 小程序？

在APP开发与小程序开发技术路径之间，本人选择了轻应用的技术开发路线，主要是相信“效率为王”，高产才能给自己赚取更高的收益。

好了，选定方向以后，接下来就是技能的学习和深入。AI的效率之高和学习成本之低，在技能深耕让我想到了是否能借助AI做更多的尝试，比如零基础开发一个页面，甚至一个小程序？

说干就干，开始着手进行准备工作：开发什么应用好呢？要不就一个简单的电商小程序吧。

一、准备工作

最开始的开始，我们先要找一个开发工具，既能帮助我们可视化的开发小程序的，又有可以接收prompt的AI能力。找度娘搜索了下，发现一款产品：FinClip的开发者工具（FinClip IDE）。

二、生成小程序

首先，随意输入一句话的提示词：

「创建一个product页面，每个product项有名称描述和单价」，看看能得出怎样的结果。

结果还是比较让人意外的，只是简单的prompt，就能得到下图的页面布局和结构，看来FinClip这个产品设计者也是很用心的，非常懂开发者的“痛”。

正所谓一个好的电影，70%都要靠导演和编导的构思，一个好的应用程序也不例外，如果要利用好AI能力，就需要有更详细的prompt规划，例如一些结构（如下），大家感兴趣的可以多尝试下：

• 内容（什么类型的小程序）：XXXXXXX


• 布局（小程序的主要页面都有什么，按钮、图片之类的）：XXXXXX


• 交互（页面上用户的使用操作）：XXXXXXX

如果prompt出来的效果并不能一次性的调整到位，FinClip的这个开发者工具还能局部修改页面代码，加上小程序页面的实时预览功能，就能够让一个开发小白尽可能的在成本输出之前进行多次调整，不得不说还是非常方便的。

其他有趣的功能，就是对于一个小程序开发小白来说，很有可能就连小程序开发语法和技术都不熟练，如何能够基于产品已有的开发文档，更便捷的进行知识提取，FinClip也通过一个AI agent连通了自有的小程序开发的知识连起来，让使用的开发者能够更好的对开发知识进行检索。

三、小结

从idea到上线，只花了2个小时，整个流程中，除了手动调整样式的数值，没有写一行代码，全部由AI能力，结合prompt帮助我完成。

这只是一次很浅层的探索案例，对我个人来说只是在小程序技能深入学习前的一个小实践，很有可能，对于熟练的前端开发来说可能就是一个小时工作量，但在这里分享的目的，是为了分享下所谓的拥抱新技术所带来的好处，与此同时，也是给大家带来一点小焦虑，正所谓“不进则退”，很多经验可能自己埋头积累并不能获得质的飞跃，最终可能自己是个"井底之蛙"，花大力气却换来了小惊喜，还不如拥抱变化，使用新技术快速提升自己的工作技能。

共勉。

背景

• 在日常开发网络请求过程中，为了维护loading和error状态开发大量重复代码


• 对于竞态问题，要么不处理，要么每个需要请求的地方都要写重复逻辑


• 图表接口数据量大，甚至单接口响应就足以达到数十兆字节，而一个页面有数十个这样的请求，响应时间长，需要能够取消网络请求

以上逻辑，每个人的解法各不相同。为了解决上述问题，统一处理逻辑，需要一个能够统一管理网络请求状态的工具。

调研

首先想到的当然不是自己搓轮子，而是在社区上寻找是否已有解决方案。果不其然，找到了一些方案。

对于React，有像react-query这样的老前辈，功能全面，大而重；有像SWR这样的中流砥柱，受到社区广泛追捧；有像ahooks的useRequest这样的小清新，功能够用，小而美。

而对于Vue，一开始还真没让我找到类似的解决方案，后续进一步查找，发现有一个外国哥们仿造react-qeury仿写了一个vue-query，同时了解到雷达团队正是用的这一套解决方案，便又更深入了解了一下，发现这个库已经不维护了......进而了解到@tanstack/query，好家伙，这玩意胃口大得把react-query和vue-query都吃进去了，甚至svelte也不放过。继续找，发现有个哥们写了一个vue-request库，差不多类似于ahooks的useRequest，不错。然后经典的vue-use库也看了下，有一个useFetch方法，比较鸡肋，只适用于Fetch请求。

上述的社区库都相当不错，但对于我来说都太重了，功能繁多，而且在使用上，几个query都需要花费大量心智在缓存key上，太难用了。而ahooks和vue-request提供的useRequest的高阶函数，是比较符合我的胃口的，但是我还是嫌他们功能太多了。最关键的是，上述所有方案都没有达到我最主要的目的，能够真正取消网络请求。

因此，自己动手，丰衣足食。

动手

说干就干，搓一个咱自己的useRequest。

首先，定义useRequest的接口：

export declare const useRequest: <P extends unknown[], R>(request: (signal: AbortSignal, ...args: P) => Promise<R>, options?: IUseRequestOptions<R> | undefined) => {

    result: ShallowRef<R | null>;

    loading: ShallowRef<boolean>;

    error: ShallowRef<Error | null>;

    run: (...args: P) => Promise<Error | R>;

    forceRun: (...args: P) => Promise<Error | R>;

    cancel: () => boolean;

};

然后定义三个响应式状态，这里之所以用shallowRef，是考虑到部分请求结果可能很深，如果用ref会导致性能很差。

const result = shallowRef<IResult | null>(null);

const loading = shallowRef(false);

const error = shallowRef<Error | null>(null);

定义普通变量，在useRequest内部使用，不要在内部实现读取响应式变量（PS：踩过坑了，有个页面用watchEffect，loading状态一变就发请求，导致无线循环）：

let abortController = new AbortController();

let isFetching = false;

然后定义run函数，如果有进行中的请求就取消掉：

const run = async (...args: IParams) => {

  if (mergedOptions.cancelLastRequest && isFetching) {

    cancel();

  }

  abortController = new AbortController();



  setLoadingState(true);



  const res = await runRequest(...args);

  return res;

};



const runRequest = async (...args: IParams) => {

  const currentAbortController = abortController;

  try {

    const res = await request(currentAbortController.signal, ...args);

    if (currentAbortController.signal.aborted) {

      return new Error('canceled');

    }

    handleSuccess(res);

    return res;

  } catch (error) {

    if (currentAbortController.signal.aborted) {

      return new Error('canceled');

    }

    handleError(error as Error);

    return error as Error;

  }

};

另外暴露出cancel方法：

const cancel = () => {

  if (isFetching) {

    mergedOptions.onCancel?.();

    setLoadingState(false);

    abortController.abort('cancel request');

    return true;

  }



  return false;

};

在组件卸载时也取消掉未完成的请求：

onScopeDispose(() => {

  if (mergedOptions.cancelOnDispose && isFetching) {

    cancel();

  }

});

以上，就是最基础版的useRequest实现，想要了解更多，欢迎直接阅读useRequest源码，核心代码一共也就一百来行。看完再把star一点，诶嘿，美滋滋。

产出

• useRequest源码


• useRequest使用文档


• 本次文章分享

收益

业务贡献

• 提供响应式的result、loading、error状态


• 内置缓存逻辑


• 内置错误重试逻辑


• 内置竞态处理逻辑


• 兼容 Vue 2 & 3


• 兼容 Axios & Fetch


• 取消网络请求

个人成长

• 学会如何编写一个基本的Vue工具库


• 了解如何用vite打包，并且带上类型文件


• 学会如何使用vue-demi兼容Vue2 & Vue3


• 学会如何用VuePress编写文档，过程中没少看源码


• 学会如何在npm上发包并维护


• 之前用jest写过测试，这次尝试了一下vitest，体感不错，过程中暴露不少代码问题


• 通过这个项目将以往所学的部分知识串联起来

参考

• SWR


• ahooks useRequest


• vue-request


• TanStack Query


• useFetch | VueUse


• AbortController - Web APIs | MDN


• 取消请求 | Axios中文文档 | Axios中文网

在本文中，我将介绍 14 款代码片段图片生成器，每款工具都具备独特功能，能够满足不同需求，帮助你将代码转化为精美、易于分享的视觉内容。无论你是追求简约设计、高度自定义，还是想要生成动态代码片段，希望这篇文章能帮助你找到合适的工具，提升代码展示的效果。

之前使用 Windows 的过程中，最痛苦的事是没有一款可以满足我快速进行记录的应用

基本都得先打开该笔记软件，然后创建新笔记，最后才能输入，这么多步骤太麻烦了

在切换到 MacOS 之后，让我惊喜的就是自带的备忘录，只需要简单地把鼠标移动到屏幕右下角，就可以创建一篇快速备忘录

Amazing！

这种方式叫做触发角，触发角可以在「系统设置 » 桌面与程序坞 » 触发角」设置：

四个触发角分别可以自由设置：

除了触发角，快捷键【 fn(🌐） + Q】同样能创建一篇快速备忘录

还有一个问题是，触发角 or 快捷键默认会打开上一次编辑的备忘录，如果想要每次都创建一篇新的快速备忘录的话，可以在设置这里：

把「始终回到上个快速备忘录」取消勾选

备忘录支持大部分高频的文本样式，选取文本后，在头部导航栏 Aa 这里做修改样式：

也能支持 check 清单：

表格功能比较弱鸡，就一个简单的表格，什么合并、冻结等高级功能都没有

另外还有图片、链接，这里就不再赘述。

备忘录默认支持文件夹分类，另外还支持标签分类，只需要在备忘录中使用井号（#）加上对应文字，Mac 即会生成对应的标签清单：

之前在浏览网页的时候，特别想高亮某些内容，同时做一些拓展记录，安装过插件 Weava Highlighter，但是不好用，每次只要选中文字就 Weava 就会弹出，特别烦人。

没想到 Mac 备忘录居然原生支持这个功能

在 Safari 中，可以选择想要收藏的内容，右键「添加到快速备忘录」

创建快速备忘录之后，选中的这句话在 Safari 中会被高亮：

在最新的 MacOS 15 中更新中，备忘录新支持了录音功能：

并且还支持实时的语言转文本，但目前又又又又仅支持英语

库克的母语是英语，我的母语是无语 😅

另外，还新增了高亮颜色，分别有紫色、粉色、橙色、薄荷色和蓝色，不得不说，这几种颜色确实还挺好看的

最有用的功能当属于这个数学功能了

直接输入像是 (27/3)^2= 或者 47*96= 算式，备忘录会自动计算结果：

还支持自定义变量：

总体来说，Mac 的备忘录还算是一个不错的笔记软件，虽然缺乏像 Notion 的文档目录结构和块编辑的一些先进笔记能力，但它有着原生的支持，能够满足快速记录和基础编辑的需求

One more thing 👇