前言：由于“无处安放”而引发的混乱

在 HTML5 普及之前，前端开发者为了在 DOM 元素上绑定一些数据（比如用户 ID、商品价格、状态码），可谓是八仙过海，各显神通：

直到 HTML5 引入了 data-*  自定义数据属性，这一切终于有了“官方标准”。

第一阶段：基础——它长什么样？

data-* 属性允许我们在标准 HTML 元素中存储额外的页面私有信息。

1. HTML 写法

语法非常简单：必须以 data- 开头，后面接上你自定义的名称。

<!-- ❌ 错误示范：不要大写，不要乱用特殊符号 -->

<div data-User-Id="1001"></div> 



<!-- ✅ 正确示范：全小写，连字符连接 -->

<div 

  id="user-card"

  data-id="1001" 

  data-user-name="juejin_expert" 

  data-value="99.9"

  data-is-vip="true"

>

  用户信息卡片

</div>

2. CSS 中的妙用

很多人以为 data-* 只是给 JS 用的，其实 CSS 也能完美利用它。

场景一：通过属性选择器控制样式

/* 当 data-is-vip 为 "true" 时，背景变金 */

div[data-is-vip="true"] {

  background: gold;

  border: 2px solid orange;

}

场景二：利用 attr() 显示数据

这是一个非常酷的技巧，可以用来做 Tooltip 或者计数器显示。

div::after {

  /* 直接把 data-value 的值显示在页面上 */

  content: "当前分值: " attr(data-value);

  font-size: 12px;

  color: #666;

}

第二阶段：进阶——JavaScript 如何读写？

这才是重头戏。在 JS 中操作 data-* 有两种方式：传统派 和 现代派。

1. 传统派：getAttribute / setAttribute

这是最稳妥的方法，兼容性最好（虽然现在也没人要兼容 IE6 了）。

const el = document.getElementById('user-card');



// 读取

const userId = el.getAttribute('data-id'); // "1001"



// 修改

el.setAttribute('data-value', '100');

特点：读出来永远是字符串。哪怕你存的是 100，取出来也是 "100"。

2. 现代派：dataset API (推荐 ✨)

HTML5 为每个元素提供了一个 dataset 对象（DOMStringMap），它将所有的 data-* 属性映射成了对象的属性。

这里有个大坑（或者说是规范），请务必注意：

HTML 中的 连字符命名 (kebab-case)  会自动转换为 JS 中的 小驼峰命名 (camelCase) 。

const el = document.getElementById('user-card');



// 1. 访问 data-id

console.log(el.dataset.id); // "1001"



// 2. 访问 data-user-name (注意变身了！)

console.log(el.dataset.userName); // "juejin_expert"

// ❌ el.dataset.user-name 是语法错误

// ❌ el.dataset['user-name'] 是 undefined



// 3. 修改数据

el.dataset.value = "200"; 

// HTML 会自动变成 data-value="200"



// 4. 删除数据

delete el.dataset.isVip;

// HTML 中的 data-is-vip 属性会被移除

💡 敲黑板：dataset 里的属性名不支持大写字母。如果你在 HTML 里写 data-MyValue="1", 浏览器会强制转为小写 data-myvalue，JS 里就得用 dataset.myvalue 访问。所以，HTML 里老老实实全小写吧。

第三阶段：深入——类型陷阱与性能权衡

1. 一切皆字符串

不管你赋给 dataset 什么类型的值，最终都会被转为字符串。

el.dataset.count = 100;        // HTML: data-count="100"

el.dataset.active = true;      // HTML: data-active="true"

el.dataset.config = {a: 1};    // HTML: data-config="[object Object]" -> 灾难！

避坑指南：

• 如果你要存数字，取出来时记得 Number(el.dataset.count)。


• 如果你要存布尔值，判断时不能简单用 if (el.dataset.active)，因为 "false" 字符串也是真值！要用 el.dataset.active === 'true'。


• 千万不要试图在 data-* 里存复杂的 JSON 对象。如果非要存，请使用 JSON.stringify()，但在 DOM 上挂载大量字符串数据会影响性能。

2. 性能考量

• 读写速度：dataset 的访问速度在现代浏览器中非常快，但在极高频操作下（比如每秒几千次），直接操作 JS 变量肯定比操作 DOM 快。


• 重排与重绘：修改 data-* 属性会触发 DOM 变更。如果你的 CSS 依赖属性选择器（如 div[data-status="active"]），修改属性可能会触发页面的重排（Reflow）或重绘（Repaint）。

第四阶段：实战——优雅的事件委托

data-value 最经典的用法之一就是在列表项的事件委托中。

需求：点击列表中的“删除”按钮，删除对应项。

<ul id="todo-list">

  <li>

    <span>学习 HTML5</span>

    <!-- 把 ID 藏在这里 -->

    <button class="btn-delete" data-id="101" data-action="delete">删除</button>

  </li>

  <li>

    <span>写掘金文章</span>

    <button class="btn-delete" data-id="102" data-action="delete">删除</button>

  </li>

</ul>

const list = document.getElementById('todo-list');



list.addEventListener('click', (e) => {

  // 利用 dataset 判断点击的是不是删除按钮

  const { action, id } = e.target.dataset;



  if (action === 'delete') {

    console.log(`准备删除 ID 为 ${id} 的条目`);

    // 这里发送请求或操作 DOM

    // deleteItem(id);

  }

});

为什么这么做优雅？

你不需要给每个按钮都绑定事件，也不需要去分析 DOM 结构（比如 e.target.parentNode...）来找数据。数据就在元素身上，唾手可得。

总结与“禁忌”

HTML5 的 data-* 属性是连接 DOM 和数据的一座轻量级桥梁。

什么时候用？

• 当需要把少量数据绑定到特定 UI 元素上时。


• 当 CSS 需要根据数据状态改变样式时。


• 做事件委托需要传递参数时。

什么时候别用？（禁忌）

最后一句：

代码整洁之道，始于不再乱用 Class。下次再想存个 ID，记得想起那个以 data- 开头的帅气属性。

Happy Coding! 🚀

前言

这是一期没有用的干货。

不知道有多少朋友的App经历过被工信部点名并下架的……显然我经历过.

几年前我的App因为违规收集个人信息被广东省通信管理局强制下架了，虽然App本身真的没有去收集个人信息，但用了架不住某些SDK喜欢做些小动作，不管怎么样，由于当时没处置，就被以侵犯用户隐私的名义给下架了。随着最近鸿蒙挺火的，我突然想试试上架一下鸿蒙。但很遗憾，全网被下架，即使新开发的鸿蒙app也不可以，所以不得不踏上申请重新上架之路。

先说一下总的感受：确实比较繁琐一些，但广东省通信管理局确实很给力，给我不少帮助。以下经验也仅适用于因为个人隐私相关问题被下架需要重新上架。

流程

首先我是在华为应用市场中问到我应该如何重新上架，然后加到粤通管网安监测的微信，然后询问如何申请重新上架。

首先，也是废话当然是要修复既存的问题。然后，将APP的整改报告及整改后的APK发送到指定邮箱，然后等待复测即可。

需要注意的是也需要将备案信息填写到整改报告中

另外，根据我查到的资料，APP侵害用户权益的检测工作是全国APP技术检测平台（APP公共服务系统）做的，并且提供了一套APP侵害用户权益专项整治行动恢复上架流程，我贴个图如下：

实际上的流程大概和这个差不多，但都是在和通信管理局打交道。这个实际体验可能因各通信管理局不同而异。

其他

还有一些小事项，比如整改报告模板，最开始的时候通信管理局也没有和我说有模板，我也在网上照猫画虎搞的。当复测通过后，填写重新上架申请书后，需要再次上传整改报告的时候，对方给我发了一个整改模板，好在经过询问，并不需要重新写一份整改模板，直接复用之前的整改报告即可。

关于整改报告里都需要有什么可以参考一下原文：

您好，APP恢复上架/小程序解除禁搜需要您单位写一份申请。说明APP被下架/小程序被禁搜的原因、具体的问题、已整改的情况、以及企业内培训宣贯情况、未来避免出现个人信息合规问题的措施、完成备案情况、承诺未来将合规经营APP/小程序及相关业务、承诺因违背承诺导致发生违规行为自愿承担法律责任及依规处罚（下架APP/禁搜小程序、关停服务器、封锁ip等）。编写好后请盖单位公章，扫描后将电子文件发送至管局邮箱 gdca_wac_app@gd.gov.cn。这边收到申请邮件后才会继续走下一步流程，请及早提交。

最后

最后磕磕绊绊还是重新上架成功，总体虽然繁琐但还是算比较顺利。不过，尽量还是别等到下线的那一刻吧。。。如果想要广东省的整改模板可以私信我。

总结一下吧：

• APP如果被通报了，要在限定时间内完成整改并上架应用商店。要不然复测的时候在应用商店没有下载到最新版本的包，问题依旧存在肯定会被下架的；


• 不幸被下架的APP企业，也不要着急。重点要做的就是先知道自己的APP具体存在哪些问题，然后有针对性的整改；


• 不知道APP问题怎么整改或者不确定APP问题是否整改到位的话，建议找个专业的第三方APP检测机构开展隐私合规检测；


• APP全部整改到位后，根据官方发布的APP恢复上架流程图逐步操作，最后等待重新上架即可。

建议：

各企业的APP一定要根据监管的要求严格落实APP个人信息保护工作，确保APP的安全和隐私合规，不要抱有侥幸心理。

最后请大家猜猜，哪个应用市场最先解禁的？哪个到现在还没解禁。

前言

这些年我参与设计过很多系统，越来越深刻地认识到：一个系统的性能如何，很大程度上取决于缓存用得怎么样。

同样是缓存，为何有人用起来系统飞升，有人却踩坑不断？

有些小伙伴在工作中可能遇到过这样的困惑：知道要用缓存，但面对本地缓存、Redis、Memcached、CDN等多种选择，到底该用哪种？

今天这篇文章跟大家一起聊聊工作中最常用的6种缓存，希望对你会有所帮助。

更多项目实战在我的技术网站：www.susan.net.cn/project

01 为什么缓存如此重要？

在正式介绍各种缓存之前，我们先要明白：为什么要用缓存？

想象这样一个场景：你的电商网站首页，每次打开都要从数据库中查询轮播图、热门商品、分类信息等数据。

如果每秒有1万个用户访问，数据库就要承受1万次查询压力。

// 没有缓存时的查询

public Product getProductById(Long id) {

    // 每次都直接查询数据库

    return productDao.findById(id); // 每次都是慢速的磁盘IO

}

这就是典型的无缓存场景。

数据库的磁盘IO速度远低于内存，当并发量上来后，系统响应变慢，数据库连接池被占满，最终导致服务不可用。

缓存的核心价值可以用下面这个公式理解：

系统性能 = (缓存命中率 × 缓存访问速度) + ((1 - 缓存命中率) × 后端访问速度)

缓存之所以能提升性能，基于两个计算机科学的基本原理：

从用户请求到数据返回，数据可能经过的各级缓存路径如下图所示：

理解了缓存的重要性，接下来我们逐一剖析这六种最常用的缓存技术。

02 本地缓存：最简单直接的性能提升

本地缓存指的是在应用进程内部维护的缓存存储，数据存储在JVM堆内存中。

核心特点

• 访问最快：直接内存操作，无网络开销


• 实现简单：无需搭建额外服务


• 数据隔离：每个应用实例独享自己的缓存

常用实现

1. Guava Cache：Google提供的优秀本地缓存库

// Guava Cache 示例

LoadingCache<Long, Product> productCache = CacheBuilder.newBuilder()

    .maximumSize(10000) // 最大缓存项数

    .expireAfterWrite(10, TimeUnit.MINUTES) // 写入后10分钟过期

    .expireAfterAccess(5, TimeUnit.MINUTES) // 访问后5分钟过期

    .recordStats() // 开启统计

    .build(new CacheLoader<Long, Product>() {

        @Override

        public Product load(Long productId) {

            // 当缓存未命中时，自动加载数据

            return productDao.findById(productId);

        }

    });



// 使用缓存

public Product getProduct(Long id) {

    try {

        return productCache.get(id);

    } catch (ExecutionException e) {

        throw new RuntimeException("加载产品失败", e);

    }

}

2. Caffeine：Guava Cache的现代替代品，性能更优

// Caffeine 示例（性能优于Guava Cache）

Cache<Long, Product> caffeineCache = Caffeine.newBuilder()

    .maximumSize(10_000)

    .expireAfterWrite(10, TimeUnit.MINUTES)

    .refreshAfterWrite(1, TimeUnit.MINUTES) // 支持刷新，Guava不支持

    .recordStats()

    .build(productId -> productDao.findById(productId));



// 异步获取

public CompletableFuture<Product> getProductAsync(Long id) {

    return caffeineCache.get(id, productId -> 

        CompletableFuture.supplyAsync(() -> productDao.findById(productId)));

}

适用场景

• 数据量不大（通常不超过10万条）


• 数据变化不频繁


• 对访问速度要求极致


• 如：配置信息、静态字典、用户会话信息（短期）

优缺点分析

• 优点：极速访问、零网络开销、实现简单


• 缺点：数据不一致（各节点独立）、内存限制、重启丢失

有些小伙伴在工作中可能会犯一个错误：在分布式系统中过度依赖本地缓存，导致各节点数据不一致。记住：本地缓存适合存储只读或弱一致性的数据。

03 分布式缓存之王：Redis的深度解析

当数据需要在多个应用实例间共享时，本地缓存就不够用了，这时需要分布式缓存。而Redis无疑是这一领域的王者。

Redis的核心优势

// Spring Boot + Redis 示例

@Component

public class ProductCacheService {

    @Autowired

    private RedisTemplate<String, Object> redisTemplate;

    

    private static final String PRODUCT_KEY_PREFIX = "product:";

    private static final Duration CACHE_TTL = Duration.ofMinutes(30);

    

    // 缓存查询

    public Product getProduct(Long id) {

        String key = PRODUCT_KEY_PREFIX + id;

        

        // 1. 先查缓存

        Product product = (Product) redisTemplate.opsForValue().get(key);

        

        if (product != null) {

            return product;

        }

        

        // 2. 缓存未命中，查数据库

        product = productDao.findById(id);

        if (product != null) {

            // 3. 写入缓存

            redisTemplate.opsForValue().set(key, product, CACHE_TTL);

        }

        

        return product;

    }

    

    // 使用更高效的方式：缓存空值防止缓存穿透

    public Product getProductWithNullCache(Long id) {

        String key = PRODUCT_KEY_PREFIX + id;

        String nullKey = PRODUCT_KEY_PREFIX + "null:" + id;

        

        // 检查是否是空值（防缓存穿透）

        if (Boolean.TRUE.equals(redisTemplate.hasKey(nullKey))) {

            return null;

        }

        

        Product product = (Product) redisTemplate.opsForValue().get(key);

        if (product != null) {

            return product;

        }

        

        product = productDao.findById(id);

        if (product == null) {

            // 缓存空值，短时间过期

            redisTemplate.opsForValue().set(nullKey, "", Duration.ofMinutes(5));

            return null;

        }

        

        redisTemplate.opsForValue().set(key, product, CACHE_TTL);

        return product;

    }

}

Redis的丰富数据结构

Redis不只是简单的Key-Value存储，它的多种数据结构适应不同场景：

集群模式选择

适用场景

• 会话存储（分布式Session）


• 排行榜、计数器


• 消息队列


• 分布式锁


• 热点数据缓存

有些小伙伴在工作中使用Redis时，只把它当简单的Key-Value用，这就像用瑞士军刀只开瓶盖一样浪费。

深入理解Redis的数据结构，能让你的系统设计更优雅高效。

04 Memcached：简单高效的分布式缓存

在Redis崛起之前，Memcached是分布式缓存的首选。

虽然现在Redis更流行，但Memcached在某些场景下仍有其价值。

Memcached vs Redis 核心区别

// Memcached 客户端示例（使用XMemcached）

public class MemcachedService {

    private MemcachedClient memcachedClient;

    

    public void init() throws IOException {

        // 创建客户端

        memcachedClient = new XMemcachedClientBuilder(

            AddrUtil.getAddresses("server1:11211 server2:11211"))

            .build();

    }

    

    public Product getProduct(Long id) throws Exception {

        String key = "product_" + id;

        

        // 从Memcached获取

        Product product = memcachedClient.get(key);

        if (product != null) {

            return product;

        }

        

        // 缓存未命中

        product = productDao.findById(id);

        if (product != null) {

            // 存储到Memcached，过期时间30分钟

            memcachedClient.set(key, 30 * 60, product);

        }

        

        return product;

    }

}

两者的核心差异对比：

何时选择Memcached？

05 CDN缓存：加速静态资源的利器

有些小伙伴可能会疑惑：CDN也算缓存吗？当然算，而且是地理位置最近的缓存。

CDN的工作原理

CDN（Content Delivery Network）通过在各地部署边缘节点，将静态资源缓存到离用户最近的节点。

// 在应用中生成CDN链接

public class CDNService {

    private String cdnDomain = "https://cdn.yourcompany.com";

    

    public String getCDNUrl(String relativePath) {

        // 添加版本号或时间戳，防止缓存旧版本

        String version = getFileVersion(relativePath);

        return String.format("%s/%s?v=%s", cdnDomain, relativePath, version);

    }

    

    // 上传文件到CDN的示例（伪代码）

    public void uploadToCDN(File file, String remotePath) {

        // 1. 上传到源站

        uploadToOrigin(file, remotePath);

        

        // 2. 触发CDN预热（将文件主动推送到边缘节点）

        preheatCDN(remotePath);

        

        // 3. 刷新旧缓存（如果需要）

        refreshCDNCache(remotePath);

    }

}

CDN缓存策略配置

# Nginx中的CDN缓存配置示例

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {

    expires 365d;  # 缓存一年

    add_header Cache-Control "public, immutable";

    

    # 添加版本号作为查询参数

    if ($query_string ~* "^v=\d+") {

        expires max;

    }

}

适用场景

• 静态资源：图片、CSS、JS文件


• 软件下载包


• 视频流媒体


• 全球访问的网站

06 浏览器缓存：最前端的性能优化

浏览器缓存是最容易被忽视但效果最直接的缓存层级。合理利用浏览器缓存，可以大幅减少服务器压力。

HTTP缓存头详解

// Spring Boot中设置HTTP缓存头

@RestController

public class ResourceController {

    

    @GetMapping("/static/{filename}")

    public ResponseEntity<Resource> getStaticFile(@PathVariable String filename) {

        Resource resource = loadResource(filename);

        

        return ResponseEntity.ok()

            .cacheControl(CacheControl.maxAge(7, TimeUnit.DAYS)) // 缓存7天

            .eTag(computeETag(resource)) // ETag用于协商缓存

            .lastModified(resource.lastModified()) // 最后修改时间

            .body(resource);

    }

    

    @GetMapping("/dynamic/data")

    public ResponseEntity<Object> getDynamicData() {

        Object data = getData();

        

        // 动态数据设置较短缓存

        return ResponseEntity.ok()

            .cacheControl(CacheControl.maxAge(30, TimeUnit.SECONDS)) // 30秒

            .body(data);

    }

}

浏览器缓存的两种类型

最近为了帮助大家找工作，专门建了一些工作内推群，各大城市都有，欢迎各位HR和找工作的小伙伴进群交流，群里目前已经收集了20多家大厂的工作内推岗位。加苏三的微信：li_su223，备注：掘金+所在城市，即可进群。

最佳实践

07 数据库缓存：容易被忽略的内部优化

数据库自身也有缓存机制，理解这些机制能帮助我们写出更高效的SQL。

MySQL查询缓存（已废弃但值得了解）

-- 查看查询缓存状态（MySQL 5.7及之前）

SHOW VARIABLES LIKE 'query_cache%';



-- 在8.0之前，可以通过以下方式利用查询缓存

SELECT SQL_CACHE * FROM products WHERE category_id = 10;

InnoDB缓冲池（Buffer Pool）

这是MySQL性能的关键，缓存的是数据页和索引页。

-- 查看缓冲池状态

SHOW ENGINE INNODB STATUS;



-- 重要的监控指标

-- 缓冲池命中率 = (1 - (innodb_buffer_pool_reads / innodb_buffer_pool_read_requests)) * 100%

-- 命中率应尽可能接近100%

数据库级缓存最佳实践

有些小伙伴可能会过度依赖应用层缓存，而忽略了数据库自身的缓存优化。

数据库缓存是最后一道防线，优化好它能让整个系统更健壮。

08 综合对比与选型指南

接下来，我给大家一个选型指南：

实战中的多级缓存架构

在实际的高并发系统中，我们往往会采用多级缓存策略：

// 多级缓存示例：本地缓存 + Redis

@Component

public class MultiLevelCacheService {

    @Autowired

    private RedisTemplate<String, Object> redisTemplate;

    

    // 一级缓存：本地缓存

    private Cache<Long, Product> localCache = Caffeine.newBuilder()

        .maximumSize(1000)

        .expireAfterWrite(30, TimeUnit.SECONDS) // 本地缓存时间短

        .build();

    

    // 二级缓存：Redis

    private static final Duration REDIS_TTL = Duration.ofMinutes(10);

    

    public Product getProductWithMultiCache(Long id) {

        // 1. 查本地缓存

        Product product = localCache.getIfPresent(id);

        if (product != null) {

            return product;

        }

        

        // 2. 查Redis

        String redisKey = "product:" + id;

        product = (Product) redisTemplate.opsForValue().get(redisKey);

        if (product != null) {

            // 回填本地缓存

            localCache.put(id, product);

            return product;

        }

        

        // 3. 查数据库

        product = productDao.findById(id);

        if (product != null) {

            // 写入Redis

            redisTemplate.opsForValue().set(redisKey, product, REDIS_TTL);

            // 写入本地缓存

            localCache.put(id, product);

        }

        

        return product;

    }

}

09 缓存常见问题与解决方案

在使用缓存的过程中，我们不可避免地会遇到一些问题：

1. 缓存穿透

问题：大量请求查询不存在的数据，绕过缓存直接击穿数据库。

解决方案：

// 缓存空值方案

public Product getProductSafe(Long id) {

    String key = "product:" + id;

    String nullKey = "product:null:" + id;

    

    // 检查空值标记

    if (redisTemplate.hasKey(nullKey)) {

        return null;

    }

    

    Product product = (Product) redisTemplate.opsForValue().get(key);

    if (product != null) {

        return product;

    }

    

    product = productDao.findById(id);

    if (product == null) {

        // 缓存空值，短时间过期

        redisTemplate.opsForValue().set(nullKey, "", Duration.ofMinutes(5));

        return null;

    }

    

    redisTemplate.opsForValue().set(key, product, Duration.ofMinutes(30));

    return product;

}

2. 缓存雪崩

问题：大量缓存同时过期，请求全部打到数据库。

解决方案：

// 差异化过期时间

private Duration getRandomTTL() {

    // 基础30分钟 + 随机0-10分钟

    long baseMinutes = 30;

    long randomMinutes = ThreadLocalRandom.current().nextLong(0, 10);

    return Duration.ofMinutes(baseMinutes + randomMinutes);

}

3. 缓存击穿

问题：热点Key过期瞬间，大量并发请求同时查询数据库。

解决方案：

// 使用互斥锁（分布式锁）

public Product getProductWithLock(Long id) {

    String key = "product:" + id;

    Product product = (Product) redisTemplate.opsForValue().get(key);

    

    if (product == null) {

        // 尝试获取分布式锁

        String lockKey = "lock:product:" + id;

        boolean locked = redisTemplate.opsForValue()

            .setIfAbsent(lockKey, "1", Duration.ofSeconds(10));

        

        if (locked) {

            try {

                // 双重检查

                product = (Product) redisTemplate.opsForValue().get(key);

                if (product == null) {

                    product = productDao.findById(id);

                    if (product != null) {

                        redisTemplate.opsForValue()

                            .set(key, product, Duration.ofMinutes(30));

                    }

                }

            } finally {

                // 释放锁

                redisTemplate.delete(lockKey);

            }

        } else {

            // 未获取到锁，等待后重试

            try { Thread.sleep(50); } 

            catch (InterruptedException e) { Thread.currentThread().interrupt(); }

            return getProductWithLock(id); // 递归重试

        }

    }

    

    return product;

}

10 总结

通过这篇文章，我们系统地探讨了工作中最常用的六种缓存技术。

每种缓存都有其独特的价值和应用场景：

缓存使用的核心原则可以总结为以下几点：

• 分级缓存：合理利用多级缓存架构


• 合适粒度：根据业务特点选择缓存粒度


• 及时更新：设计合理的缓存更新策略


• 监控告警：建立完善的缓存监控体系

有些小伙伴在工作中使用缓存时，容易陷入两个极端：要么过度设计，所有数据都加缓存；要么忽视缓存，让数据库承受所有压力。

我们需要懂得在合适的地方使用合适的缓存，在性能和复杂性之间找到最佳平衡点。

记住，缓存不是银弹，而是工具箱中的一件利器。

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙关注一下我的同名公众号：苏三说技术，您的支持是我坚持写作最大的动力。

求一键三连：点赞、转发、在看。

关注公众号：【苏三说技术】，在公众号中回复：进大厂，可以免费获取我最近整理的10万字的面试宝典，好多小伙伴靠这个宝典拿到了多家大厂的offer。

更多项目实战在我的技术网站：http://www.susan.net.cn/project

先声明，本文不是贩卖焦虑，只是自己的一点拙见，没有割韭菜的卖课、副业、保险广告，请放心食用。

2022 年初，前司开始了轰轰烈烈的「降本增笑」运动，各部门严格考核机器成本和预算。当然，最重要的还是「开猿节流」。

幸好，我所在部门是盈利的，当时几乎没有人受到波及。

据说，现在连餐巾纸都从三层的「维达」换成两层的「心心相印」了，号称年节约成本 100 多万。我好奇的是，擦屁股时多少会沾点 💩 吧？这下，真是名正言顺的 💩 山代码了。

2022 年 7 月底，因为某些原因，结束 10 年北漂回老家，换了个公司继续搬砖。

2023 年，春节后不久，现司搞「偷袭」，玩起了狼人杀，很多小伙伴被刀：

清晨接到电话通知，上午集体开会，IT 收回权限，中午滚蛋

好在是头一回，补偿非常可观，远超法律规定的「N+1」。

2024 年，平安夜，无事发生。

2025 年 1 月，公司年会，趣味运动会，有个项目是「财源滚滚」，下图这样的：

有个参赛的老哥调侃道，这项目名字不吉利啊，不应该参加的。无巧不成书，年后他被刀了。。。

这次的规模远小于 2023 年，但 2025 年也不太平，「脉脉」上陆续有人说被刀或者不续签，真假未知。

实话说，我之前从未担心过被裁，毕竟：

名校硕士，经历多个大厂，有管理经验

热爱编程，工作认真负责，常年高绩效

但是，随着 AI 的快速迭代，我现在感觉自己随时可能被刀了。AI 能胜任 log 分析、新功能开发、bug 修复等绝大部分日常工作，而且都完成的很好。再配合 AI 自己写的MCP，效率肉眼可见的提高。

亲身体验，数百人开发的千万行代码级别的项目，混合了Java/Kotlin/OC/C++/Python等各种语言。跟Cursor聊了几句，它就找到原因并帮忙修复了。如果是自己看代码、问人、加 log、编译，至少得半个小时。

那还要码农干啥呢？即使是留下来背锅，也要不了这么多啊。

距离上次「狼人杀 」，三年之期已到。今年会有「狼人杀 2.0」吗？我还能平稳落地吗？

无所谓了，我早已准备好后路：

头盔和衣服真是我买的，还有手套未入镜，我感觉设计很漂亮，等天气暖和后，当骑行服穿。

汽车，小踏板，大踏板，足以覆盖滴滴、外卖、闪送三大朝阳行业。家里还有个小电驴，凑合能放到后备箱，承接代驾业务问题不大。

以上，虽然是开玩笑，但我对「是否被刀、何时被刀」，真的是无所谓。因为：

一个人的命运啊，当然要靠自我奋斗，但也要考虑历史的进程

公司为了长远的发展，刀人以降低成本，再用 AI 来提高效率，求得股价长红。对此，我十分理解，换我当老板，也会这么干。

作为牛马，想太多没用，我们左右不了这些事。不夸张的说，99.9999% 的码农是不可能干到退休的，和死亡一样，被刀只是早晚的事。更扎心的是：

人不是老了才会死，而是随时会死

当下的工作也一样，并不是摸鱼或者捅娄子才会被刀，而是随时会被刀，与个人的努力、绩效关系不大。常年健身的肌肉男，也可能猝死，只是概率低点，并不是免死金牌。

生命，从受精的那一刻起，就在走向终点。工作，从入职的那一刻起，就在走向(主动/被动)离职。

所以，虽然我现在感觉自己随时可能被 AI 替代，但我的心态一直都没变，就是标题所言：

做好自己的份内工作，等着被裁

不是消极怠工，我始终认真完成每一项任务，该加班加班。并非为了绩效，是因为自己的责任心，要对的起工资。至于公司哪天让我滚蛋，我决定不了，更改变不了。就像对待死亡一样，坦然接受之，给够补偿就好。

对于 AI，还想再啰嗦两句：

滚蛋之后呢？我不知道，现在有多少公司愿意招 40 岁高龄码农？据说前司招聘 35 岁普通员工都要 VP 审批了，真是小刀剌屁股，开了眼了。

好在，我家人的物质欲望极低，对衣服、手机、汽车没有任何追求，老婆不用化妆品和护肤品，也没买过一个包。即使不上班，积蓄也能撑一段时间。

所以，强烈建议当前北上广深拿高薪的老哥老妹们，除非万不得已，千万不要像我一样断崖式降薪回老家。趁年轻，搞钱比啥都重要。

对了，我目前有两个利用自身优势的基于 AI 的创业方向。网友们帮忙把把关，如果哪天真失业了，看能否拉到几个亿的风投，谢谢！

离职转AI独立开发半年，我感受到了真正的生活

我的新产品：code.lucids.top/

开场白：一个不被理解的决定

2022年12月的最后一天，我收拾了自己的小盒子，里面装着我在这家互联网公司工作的所有痕迹：一个定制水杯，几本技术书籍，和一摞写满代码思路的便利贴。HR部门的小姐姐看着我签完最后一份文件，表情有些复杂："小张，你才来半年就走，真的想好了吗？这个时候辞职，外面行情不好..."

我点点头，没多解释。如何向别人解释我这个2000年出生的"孩子"，毕业仅仅半年就对光鲜的互联网工作心生倦意？如何解释我不想再每天凌晨两点被产品经理的消息惊醒，然后爬起来改几行代码？如何解释我想追求的不只是一份体面的工资和一个看起来不错的头衔？

当我走出公司大楼，北京的冬风刮得我脸生疼。我的储蓄只够支撑我半年，而我计划做的事情——成为一名AI独立开发者——在大多数人眼中无异于天方夜谭。"你疯了吧？现在的独立开发者，有几个能养活自己的？"这是我最好朋友听到我计划时的反应。

事实证明，他错了。我也曾经错了。而现在，当我坐在自己选择的咖啡馆，以自己喜欢的节奏工作，看着用户数突破10,000的后台数据，我知道这半年的挣扎、焦虑和不安都是值得的。

职场困境：我在互联网大厂的日子

回想起入职的第一天，一切都充满希望。校招拿到知名互联网公司的offer，年薪30万，比许多同学高出不少。父母骄傲地向亲戚们宣布他们的儿子"找到了好工作"。

然而现实很快给了我当头一棒。

我被分到一个负责内部工具开发的小组。领导在入职第一天就明确告诉我："小张，我们这个组不是核心业务，资源有限，但任务不少，你得做好加班的准备。"

第一个月，适应期，我每天工作10小时，感觉还能接受。到了第二个月，一个重要项目启动，我开始习惯每天凌晨回家，第二天早上9点又准时出现在公司。最夸张的一次，我连续工作了38个小时，只为了赶一个莫名其妙被提前的deadline。

# 当时的我就像这段无限循环的代码

while True:

    wake_up()

    go_to_work()

    coding_till_midnight()

    get_emergency_task()

    sleep(2)  # 只睡2小时

工作内容也让我倍感挫折。作为一名热爱技术的程序员，我希望能够参与有挑战性的项目，学习前沿技术。但现实是，我大部分时间都在做重复性的维护工作，修复一些简单但繁琐的bug，或者应对产品经理们不断变化的需求。

我感到自己正在成为一个"代码工具人"，一个可以被随时替换的齿轮。我的创造力，我对技术的热情，我想为这个世界带来一些改变的梦想，都在日复一日的996中渐渐磨灭。

转折点：AI浪潮中看到的希望

2022年底，ChatGPT横空出世。作为一个技术爱好者，我第一时间注册了账号，体验了这个令人震惊的产品。我记得那天晚上，我熬夜到凌晨三点，不断地与ChatGPT对话，测试它的能力边界。

"这太不可思议了，"我对自己说，"这将改变一切。"

随后几周，我利用所有空闲时间（其实并不多）研究OpenAI的API文档，尝试构建一些简单的应用。我发现，大语言模型（LLM）并不像我想象的那样遥不可及，即使是一个普通开发者，只要理解其工作原理，也能基于它创造出有价值的产品。

同时，我开始关注独立开发者社区。我惊讶地发现，有不少人依靠自己开发的小产品，实现了不错的收入。虽然他们中的大多数人都经历了长期的积累，但AI技术的爆发似乎提供了一个弯道超车的机会。

这个想法越来越强烈，直到有一天晚上，当我又一次被加到一个紧急项目里，领导发来消息："小张，这个需求很紧急，今晚能上线吗？"

我望着窗外的夜色，突然感到一阵前所未有的清晰。

我回复道："可以，这是我在公司的最后一个项目了。"

第二天，我提交了辞职申请。

技术探索：从零开始的AI学习之路

辞职后的第一个月，我给自己制定了严格的学习计划。每天早上6点起床，先锻炼一小时，然后开始我的"AI课程"。

首先，我需要理解大语言模型的基本原理。虽然我有编程基础，但NLP和深度学习对我来说仍是比较陌生的领域。我从《Attention is All You Need》这篇奠定Transformer架构的论文开始，通过各种在线资源，逐步理解了当代大语言模型的工作机制。

# 简化的Transformer注意力机制示例

def scaled_dot_product_attention(query, key, value, mask=):

    # 计算注意力权重

    matmul_qk = tf.matmul(query, key, transpose_b=True)

    

    # 缩放

    depth = tf.cast(tf.shape(key)[-1], tf.float32)

    logits = matmul_qk / tf.math.sqrt(depth)

    

    # 添加掩码（可选）

    if mask is not :

        logits += (mask * -1e9)

        

    # softmax归一化

    attention_weights = tf.nn.softmax(logits, axis=-1)

    

    # 应用注意力权重

    output = tf.matmul(attention_weights, value)

    

    return output, attention_weights

然后，我需要掌握如何有效地利用OpenAI、Anthropic等公司提供的API。这包括了解Prompt Engineering的技巧，学会如何构建有效的提示词，以及如何处理模型输出的后处理工作。

我还深入研究了向量数据库、检索增强生成（RAG）等技术，这些对于构建基于知识的AI应用至关重要。

$Similarity(A, B) = \frac{A \cdot B}{|A| \times |B|} = \cos(\theta)$

这个余弦相似度公式成为了我日常工作的一部分，用于计算文本嵌入向量之间的相似性。

同时，我不断实践、不断失败、不断调整。我记得有一周，我几乎每天睡眠不足5小时，只为解决一个模型幻觉问题。但与公司工作不同的是，这种忙碌源于我的热情和对问题的好奇，而非外部压力。

产品孵化：从创意到实现

学习的同时，我开始思考自己的产品定位。在观察市场和分析自身技能后，我决定开发一款面向内容创作者的AI助手，我将其命名为"创作魔法师"。

这个产品的核心功能是帮助博主、自媒体人和营销人员高效创作内容。与市面上的通用AI不同，它专注于内容创作流程：从选题分析、结构规划、初稿生成到细节优化和SEO改进，提供全流程支持。

产品开发过程中，我遇到了许多挑战：

最艰难的时刻是产品上线后的第一个月。用户增长缓慢，每天只有个位数的新注册。我开始怀疑自己的决定，甚至一度考虑放弃，重新找工作。

转机：从10个用户到10,000用户

转机出现在上线后的第二个月。一位拥有20万粉丝的自媒体创作者使用了我的产品，对效果非常满意，在他的平台上分享了使用体验。这篇分享在创作者圈内引起了不小的反响。

24小时内，我的注册用户从原来的不到200人猛增至1500多人。服务器一度崩溃，我熬夜进行紧急扩容和优化。这次意外的曝光让我意识到，产品定位是正确的，市场需求确实存在。

接下来，我调整了运营策略：

// 用户增长追踪系统的一部分

function trackUserGrowth() {

  const date = new Date().toISOString().split('T')[0];

  

  db.collection('metrics').updateOne(

    { date: date },

    { 

      $inc: { 

        newUsers: 1,

        totalImpressions: userSource.impressions || 0

      },

      $set: {

        lastUpdated: new Date()

      } 

    },

    { upsert: true }

  );

}

三个月后，用户数突破5,000；半年后，达到10,000。更令人欣慰的是，付费转化率远超我的预期，达到了8%左右，而行业平均水平通常在2-3%。

我分析了成功原因：

财务自由：从赤字到收支平衡

谈到收入模式，我采用了"免费+订阅"的策略：

• 基础功能完全免费，足以满足普通用户的需求


• 高级功能（如批量处理、高级模板、深度分析等）需要订阅


• 提供月度计划（49元）和年度计划（398元，约33元/月）

最初几个月，收入微乎其微。我记得第一个月的收入仅有287元，而我在公司的月薪是25,000元。差距之大，让我一度怀疑自己的决定。

但随着用户增长，情况逐渐改善。第三个月收入突破5,000元，第四个月达到12,000元，第六个月——也就是我离职半年后，月收入达到了23,500元，基本与我原来的工资持平。

考虑到我现在的生活成本降低了（不需要租住在北京市中心的高价公寓，不需要每天通勤），实际上我的生活质量反而提高了。

更重要的是，这些收入是真正属于我的，不依赖于任何公司的评价和KPI。我建立了自己的"被动收入引擎"，它可以在我睡觉时继续为我工作。

生活平衡：找回被工作吞噬的自我

收入只是故事的一部分。对我来说，最大的变化是生活方式的改变。

在互联网公司工作时，我的生活可以用一句话概括：工作即生活。我几乎没有个人时间，健康状况逐渐恶化，社交圈萎缩到只剩同事，爱好被束之高阁。

成为独立开发者后，我重新掌控了自己的时间：

• 合理作息：我不再熬夜加班，保持每天7-8小时高质量睡眠。


• 定期锻炼：每天至少运动一小时，半年下来体重减轻10kg，体脂率降低5%。


• 地点自由：我可以在家工作，也可以去咖啡馆，甚至尝试了几次"工作旅行"，边旅游边维护产品。


• 深度学习：不再为了应付工作而学习，而是追随个人兴趣深入研究技术。


• 重拾爱好：我重新开始弹吉他，参加了当地的音乐小组，结识了一群志同道合的朋友。

这种生活方式让我找回了工作的意义——工作是为了更好的生活，而不是生活为了工作。我的创造力和工作热情反而因此提升，产品迭代速度和质量都超出了预期。

技术反思：AI时代的个人定位

在这半年的独立开发经历中，我对AI技术和个人发展有了更深的思考。

首先，大模型时代确实改变了软件开发的范式。传统开发模式是"写代码解决问题"，而现在更多的是"设计提示词引导AI解决问题"。这不意味着编程技能不重要，而是编程与AI引导能力的结合变得越来越重要。

# 传统开发方式

def analyze_sentiment(text):

    # 复杂的NLP算法实现

    words = tokenize(text)

    scores = calculate_sentiment_scores(words)

    return determine_overall_sentiment(scores)



# AI时代的开发方式

def analyze_sentiment_with_llm(text):

    prompt = f"""

    分析以下文本的情感倾向，返回'正面'、'负面'或'中性'。

    只返回分类结果，不要解释。

    文本: {text}

    """

    result = llm_client.generate(prompt, max_tokens=10)

    return result.strip()

其次，我认识到技术民主化的力量。曾经需要一个团队才能完成的项目，现在一个人借助AI工具也能完成。这为独立开发者创造了前所未有的机会，但也意味着差异化和创新变得更加重要。

最后，我发现真正的核心竞争力不在于熟悉某项技术，而在于解决问题的思维方式和对用户需求的理解。技术工具会不断更新迭代，但洞察问题和设计解决方案的能力将长期有效。

写给迷茫的年轻人

回顾这半年的经历，我想对那些和当初的我一样迷茫的年轻人说几句话：

未来展望：持续进化的旅程

现在，我站在新的起点上。"创作魔法师"只是我旅程的第一步，我已经开始规划下一个产品，瞄准了另一个我认为有潜力的细分市场。

与此同时，我也在考虑如何扩大团队规模。虽然独立开发有其魅力，但有些想法需要更多元的技能组合才能实现。我计划在未来半年内招募1-2名志同道合的伙伴，组建一个小而精的团队。

技术上，我将继续深入研究大模型的微调和部署技术。随着开源模型的进步，在特定领域微调自己的模型变得越来越可行，这将是我产品的下一个竞争优势。

生活方面，我正计划一次为期两个月的"数字游牧"之旅，边旅行边工作，探索更多可能的生活方式。

路上会有挑战，也会有挫折，但我不再惧怕。因为我知道，真正的自由不在于没有困难，而在于面对困难时仍能按自己的意愿选择前进的方向。

当我在咖啡馆工作到黄昏，看着窗外的夕阳，我常常感到一种难以言喻的满足感。这种感觉告诉我，我正在正确的道路上——一条通往真正生活的道路。

如果你也在考虑类似的选择，希望我的故事能给你一些启发。记住，每个人的路都不同，重要的是找到属于自己的节奏和方向。

在这个AI加速发展的时代，机会前所未有，但终究，技术只是工具，生活才是目的。

前言

昨天在Code Review时，我发现阿城在Service层直接返回了Result对象。

指出这个问题后，阿城有些不解，反问我为什么不能这样写。

于是我们展开了一场技术讨论（battle 🤣）。

讨论过程中，我发现这个看似简单的设计问题，背后其实涉及分层架构、职责划分、代码复用等多个重要概念。

与其让这次讨论的内容随风而去，不如整理成文，帮助更多遇到同样困惑的朋友理解原因。

知其然，更知其所以然。

耐心看完，你一定有所收获。

职责分离原则

在传统的MVC架构中，Service层和Controller层各自承担着不同的职责。

Service层负责业务逻辑的处理，而Controller层负责HTTP请求的处理和响应格式的封装。

当我们将数据包装成 Result 对象的任务交给 Service 层时，意味着 Service 层不再单纯地处理业务逻辑，而是牵涉到了数据处理和响应的部分。

这样会导致业务逻辑与表现逻辑的耦合，降低了代码的清晰度和可维护性。

看一个不推荐的写法:

@Service

publicclass UserService {

    public Result<User> getUserById(Long id) {

        User user = userMapper.selectById(id);

        if (user == null) {

            return Result.error(404, 用户不存在);

        }

        return Result.success(user);

    }

}



@RestController

publicclass UserController {

    @Autowired

    private UserService userService;

    

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

    public Result<User> getUser(@PathVariable Long id) {

        return userService.getUserById(id);

    }

}

上面代码中，Service 层不仅负责从数据库获取用户信息，还直接处理了返回的结果。

如果我们需要改变返回的格式，或者进行错误信息的标准化，所有 Service 层的方法都需要修改。这样会导致代码的高耦合。

相比之下，以下做法将展示逻辑留给 Controller 层，保证了业务逻辑的纯粹性：

@Service

publicclass UserService {

    public User getUserById(Long id) {

        User user = userMapper.selectById(id);

        if (user == null) {

            thrownew BusinessException(用户不存在);

        }

        return user;

    }

}



@RestController

publicclass UserController {

    @Autowired

    private UserService userService;

    

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

    public Result<User> getUser(@PathVariable Long id) {

        User user = userService.getUserById(id);

        return Result.success(user);

    }

}

让每一层都专注于自己的职责。

可复用性问题

当Service层返回Result时，会严重影响方法的可复用性。

假设我们有一个订单服务需要调用用户服务:

@Service

publicclass OrderService {

    @Autowired

    private UserService userService;

    

    public void createOrder(Long userId, OrderDTO orderDTO) {

        // 不推荐的方式:需要解包Result

        Result<User> userResult = userService.getUserById(userId);

        if (!userResult.isSuccess()) {

            thrownew BusinessException(userResult.getMessage());

        }

        User user = userResult.getData();

        

        // 后续业务逻辑

        validateUserStatus(user);

        // ...

    }

}

这种写法有个很明显的问题。

OrderService 作为另一个业务服务，业务之间的调用本来应该简单直接，但使用 Result 带来了两个问题：

• 不知道 Result 里到底包含什么，还得去查看代码里面的实现，写起来麻烦。


• 还需要额外判断 Result 的状态，增加了不必要的复杂度。

如果是调用第三方外部服务，需要这种包装还能理解，但在自己业务之间互相调用时，完全没必要这样做。

如果Service返回纯业务对象:

@Service

public class OrderService {

    @Autowired

    private UserService userService;

    

    public void createOrder(Long userId, OrderDTO orderDTO) {

        // 推荐的方式:直接获取业务对象

        User user = userService.getUserById(userId);

        

        // 后续业务逻辑

        validateUserStatus(user);

        // ...

    }

}

代码变得简洁且符合直觉。

业务层之间直接传递业务对象，保持简单和清晰。

异常处理机制

有些 Service 层在业务判断失败后，会直接返回 Result.fail(xxx) 这样的代码，例如：

public Result<Void> createOrder(Long userId, OrderDTO orderDTO) {

    if (userId == null) {

        return Result.fail("用户ID不能为空");

    }

    // 后续业务逻辑

    return Result.success();

}

这种做法有几个问题：

• 重复的错误处理：  每个方法都得写一大堆类似的错误判断代码，增加了代码量。


• 错误分散：  错误处理分散在每个方法里，如果需要改进错误逻辑，要在多个地方修改，麻烦且容易出错。

而如果我们通过抛出异常并结合全局异常处理来统一处理错误，例如：

public void createOrder(Long userId, OrderDTO orderDTO) {

    if (userId == null) {

        throw new BusinessException("用户ID不能为空");

    }

    // 后续业务逻辑

}

再通过全局异常捕获来转换为 Result：

@RestControllerAdvice

public class GlobalExceptionHandler {

    @ExceptionHandler(BusinessException.class)

    public Result<Void> handleBusinessException(BusinessException e) {

        return Result.error(400, e.getMessage());

    }



    @ExceptionHandler(Exception.class)

    public Result<Void> handleException(Exception e) {

        log.error("系统异常", e);  // 这里可以查看堆栈信息

        return Result.error(500, "系统繁忙");

    }

}

这样做的好处是：

减少重复代码：业务方法不再需要写重复的错误判断，代码更简洁。

• 集中错误处理：  错误处理集中在一个地方，修改时只需修改全局异常处理器，不用改动每个 Service 层方法。


• 业务与错误分离：  业务逻辑专注处理核心功能，错误处理交给统一的机制，代码更加清晰易懂。

而且异常可以携带更丰富的上下文信息，如果业务侧需要时，可以带上堆栈信息，便于一些问题的定位。

测试便利性

Service层返回业务对象而不是Result时，能够大大提升单元测试的便利性:

@SpringBootTest

publicclass UserServiceTest {

    

    @Autowired

    private UserService userService;

    

    @Test

    public void testGetUserById() {

        // 推荐的方式:直接断言业务对象

        User user = userService.getUserById(1L);

        assertNotNull(user);

        assertEquals(张三, user.getName());

    }

    

    @Test

    public void testGetUserById_NotFound() {

        // 推荐的方式:断言抛出异常

        assertThrows(BusinessException.class, () -> {

            userService.getUserById(999L);

        });

    }

}

如果Service返回Result，测试代码则需要写得更复杂:

@Test

public void testGetUserById() {

    // 不推荐的方式:需要解包Result

    Result<User> result = userService.getUserById(1L);

    assertTrue(result.isSuccess());

    assertNotNull(result.getData());

    assertEquals(张三, result.getData().getName());

}

测试代码变得莫名冗长，还得去关注响应结构，这并不是Service层测试的关注点。

Service 层本应专注于业务逻辑，测试也应该直接验证业务数据。

领域驱动设计角度

再换个角度。

从领域驱动设计（DDD）的角度来看，Service 层属于应用层或领域层，应该使用领域语言来表达业务逻辑。

而 Result 是基础设施层的概念，代表 HTTP 响应格式，不应该污染领域层。

例如，考虑转账业务：

@Service

publicclass TransferService {

    

    public TransferResult transfer(Long fromAccountId, Long toAccountId, BigDecimal amount) {

        Account fromAccount = accountRepository.findById(fromAccountId);

        Account toAccount = accountRepository.findById(toAccountId);

        

        fromAccount.deduct(amount);

        toAccount.deposit(amount);

        

        accountRepository.save(fromAccount);

        accountRepository.save(toAccount);

        

        returnnew TransferResult(fromAccount, toAccount, amount);

    }

}

在这个例子中，TransferResult 是一个领域对象，代表了转账的结果，包含了与业务相关的意义，而不是一个通用的 HTTP 响应封装 Result。

这种做法更符合领域模型的表达，体现了领域层的职责——处理业务逻辑，而不是涉及 HTTP 响应格式的细节。

接口适配的灵活性

当 Service 层返回纯粹的业务对象时，Controller 层可以根据不同的接口需求灵活封装响应：

@RestController

@RequestMapping("/api")

publicclass UserController {

    

    @Autowired

    private UserService userService;

    

    // REST接口返回Result

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

    public Result<User> getUser(@PathVariable Long id) {

        User user = userService.getUserById(id);

        return Result.success(user);

    }

    

    // GraphQL接口直接返回对象

    @QueryMapping

    public User user(@Argument Long id) {

        return userService.getUserById(id);

    }

    

    // RPC接口返回自定义格式

    @DubboService

    publicclass UserRpcServiceImpl implements UserRpcService {

        public UserDTO getUserById(Long id) {

            User user = userService.getUserById(id);

            return convertToDTO(user);

        }

    }

}

同一个Service方法可以被不同类型的接口复用，每个接口根据自己的协议要求封装响应。

强行使用 Result 会导致接口的适配性变差，无法根据不同协议的需求灵活定制响应格式。

灵活性反而丢失了。

事务边界清晰

Service 层通常是事务边界所在，当 Service 返回业务对象时，事务的语义更加清晰：

@Service

publicclass OrderService {

    

    @Transactional

    public Order createOrder(OrderDTO orderDTO) {

        Order order = new Order();

        // 设置订单属性

        orderMapper.insert(order);

        

        // 扣减库存

        inventoryService.deduct(orderDTO.getProductId(), orderDTO.getQuantity());

        

        return order;

    }

}

在这个例子中，事务是围绕 Service 层的方法展开的，@Transactional 注解确保在业务逻辑执行失败时，事务会回滚。因为方法正常返回时，事务会提交；如果抛出异常，事务会回滚，事务的边界非常明确。

如果 Service 返回的是 Result，很难界定事务是否应该回滚。比如：

public Result<Order> createOrder(OrderDTO orderDTO) {

    Order order = new Order();

    // 设置订单属性

    orderMapper.insert(order);

    

    // 扣减库存

    Result<Void> inventoryResult = inventoryService.deduct(orderDTO.getProductId(), orderDTO.getQuantity());

    if (!inventoryResult.isSuccess()) {

        return Result.fail("库存不足");

    }

    

    return Result.success(order);

}

在这种情况下，如果库存不足，虽然 Result 返回失败信息，但事务并不会回滚，可能会导致数据不一致，反而还得额外去抛出异常。

而通过抛出异常的方式，事务的回滚语义非常清晰：异常抛出则回滚，方法正常返回则提交，这种设计确保了事务的边界更加明确，避免了潜在的数据一致性问题。

在现代 Web 开发中，技术 SEO 是确保网站能够被搜索引擎正确索引和排名的关键。

不做 SEO：

• 网站处于隐形状态：除非用户直接输入网站，否则没人能通过搜索找到你的网站


• 收录混乱：搜索引擎不收录你的页面，或是收录的无效页面


• 仅能靠付费推广：想要流量只能付费做广告或者社交媒体推广


• 裸链接：用户分享网址时只能是蓝色 URL 链接，可能被识别为垃圾信息


• 品牌信任度：用户难以搜索到网站，降低网站的可信度

做了 SEO：

• 主动被发现：搜索关键词时你的网站会得到推荐，增加流量


• 收录全面：搜索引擎知道网站有哪些页面，网站内容更新后会很快被搜索到


• 免费且持久：搜索引擎会长期维护你的网站，排名稳定后，会有源源不断的流量


• 优雅的展示封面：分享会展示精美的网站封面，提升用户点击率


• 技术红利：做了 SEO，会优化内容结构，变相提升网站的技术


• 背书效应：用户潜意识里认为排在前面的网站更权威、更正规

SEO 这么有用，但一般人的实现却是：

• 加个 <title> 标签


• 加几个 <meta> 关键词

真正有用、高效的 SEO 要怎么做呢？

SEO 核心概念

先来了解一下 SEO 的一些核心概念。

sitemap.xml 是什么？

• 作用：给搜索引擎指路


• 功能：
  
  
  
  
  • 列出你希望被收录的所有页面
  
  
  • 告诉页面更新时间、优先级
  
  
  
  


• 示例

<url>

  <loc>https://xxx.com/page1</loc>

  <lastmod>2026-02-12</lastmod>

  <priority>0.8</priority>

</url>

robots.txt 是什么？

• 作用：给搜索引擎定规矩


• 功能：
  
  
  
  
  • 禁止某些爬虫
  
  
  • 禁止爬某些目录 / 页面
  
  
  • 告诉爬虫去哪里找 sitemap
  
  
  
  


• 示例

User-agent: *

Disallow: /admin/

Disallow: /private.html

Allow: /

Sitemap: https://xxx.com/sitemap.xml

Schema.org 是什么？

• 作用

给 Google、百度、必应 等搜索引擎看的，告诉它们：

• 这是什么内容（文章？产品？视频？人？）


• 标题是什么


• 发布时间


• 作者


• 评分


• 目录结构


• 功能
  
  
  
  
  • 让搜索结果更美观、更丰富（显示标题、图、时间、作者）
  
  
  • 让搜索引擎更懂你页面内容
  
  
  • 提升 SEO 效果
  
  
  
  


• 示例

<script type="application/ld+json">

  {

    "@context": "https://schema.org",

    "@type": "Article",

    "headline": "文章标题",

    "author": { "@type": "Person", "name": "作者" }

  }

</script>

OG Image 是什么？

当你把网页分享到微信、QQ、抖音、小红书、Discord、Facebook时，显示的那张封面图，就是 OG Image。

• 作用
  
  
  
  
  • 控制分享出去长什么样
  
  
  • 没有它，分享可能没封面图、显示效果差
  
  
  
  


• 功能
  
  
  
  
  • 优化分享效果
  
  
  • 提升社交媒体分享的点击率和用户互动
  
  
  
  


• 示例

<meta property="og:title" content="标题" />

<meta property="og:description" content="描述" />

<meta property="og:image" content="https://xxx.com/cover.jpg" />

Nuxt SEO

Nuxt SEO 是一套 SEO 元模块，其中包含多个模块：

核心优势：

• 自动化：自动生成 robots.txt、sitemap.xml 和 og:image。


• 最佳实践：默认遵循 Google 等搜索引擎的推荐标准。


• 开发体验：与 Nuxt DevTools 深度集成，提供实时的 SEO 调试能力。

快速开始

了解完以上概念后，接下来开始提升网站的 SEO 效果。

安装

pnpm i @nuxtjs/seo

配置

在 nuxt.config.ts 中进行配置。最重要的是设置 site.url，它是生成 Sitemap 和 Canonical URL 的基础。

export default defineNuxtConfig({

  modules: ["@nuxtjs/seo"],

  site: {

    url: "https://example.com", // 网站域名

    name: "我的 Nuxt 应用",

    description: "一个高性能的 Nuxt 网站",

    defaultLocale: "zh-CN", // 设置默认语言

  },

})

开发调试

安装了 @nuxtjs/seo 后，启动项目打开 Nuxt DevTools，你会发现一个新的 SEO 选项卡：

• 实时检查：查看当前页面的 Meta 标签、OG 图片预览和 Schema 数据。


• 缺失提示：如果页面缺少关键的 SEO 信息（如 Title 或 Description），DevTools 会给出警告。

进阶配置

虽然 @nuxtjs/seo 已经提供了开箱即用的配置，但在实际生产环境中，我们往往需要更精细的控制。

@nuxtjs/sitemap

sitemap.xml 是搜索引擎发现你网站页面的地图。@nuxtjs/sitemap 模块会自动扫描你的静态路由，但对于动态内容（如博客文章、商品详情），我们需要手动告知它。

常用配置

// nuxt.config.ts

export default defineNuxtConfig({

  sitemap: {

    // 1. 动态路由数据源：支持 API 端点

    sources: ["/api/__sitemap__/urls"],

    // 2. 排除不需要被索引的页面

    exclude: ["/user/**", "/admin/**", "/checkout"],

    // 3. 开启分块 (Chunking)：适用于大型网站 (> 50k URL)

    sitemaps: true,

  },

})

★

对于动态路由，你可以创建一个 Server API (例如 server/api/__sitemap__/urls.ts) 来返回所有的文章链接。

如何验证配置是否生效？

本地启动项目，访问：http://localhost:3000/sitemap.xml；线上环境访问：https://yoursite.com/sitemap.xml，当看到 xml 内容既配置成功。

@nuxtjs/robots

robots.txt 定义了爬虫可以访问哪些区域。@nuxtjs/robots 的一大优势是它能根据环境自动切换策略：开发环境默认禁止所有爬虫，生产环境默认允许。

// nuxt.config.ts

export default defineNuxtConfig({

  robots: {

    // 1. 全局爬虫规则（User-agent: * 对应 allRobots）

    allRobots: {

      // 禁止爬取的目录/页面（常用）

      Disallow: [

        "/admin/", // 后台管理页

        "/api/", // 接口目录

        "/_nuxt/", // Nuxt 打包后的静态资源（可选，一般无需禁止）

        "/private/", // 私有页面

        "/*.pdf$", // 禁止爬取所有 PDF 文件（正则写法）

      ],

      // 允许爬取的内容（覆盖 Disallow，可选）

      Allow: [

        "/api/public/", // 允许爬取公开接口

      ],

      // 爬虫抓取频率（可选，只是建议，非强制）

      CrawlDelay: 2, // 每次请求间隔 2 秒，减轻服务器压力

    },

    // 添加自定义规则

    groups: [

      {

        userAgent: ["Baiduspider"], // 针对百度爬虫的特殊规则

        disallow: ["/api/"], // 禁止访问

        allow: ["/api/public-data"], // 允许访问

      },

      {

        userAgent: "*",

        disallow: ["/secret", "/admin"],

        allow: "/",

      },

    ],

  },

})

如何验证配置是否生效？

本地启动项目，访问：http://localhost:3000/robots.txt；线上环境访问：https://yoursite.com/robots.txt，会看到以下内容:

User-agent: *

Disallow: /admin/

Disallow: /api/

Disallow: /private/

Allow: /

Crawl-delay: 2

Sitemap: https://你的域名.com/sitemap.xml



User-agent: Baiduspider

Disallow: /archive/

nuxt-og-image

全局配置

// nuxt.config.ts

export default defineNuxtConfig({

  modules: ["@nuxtjs/seo"],

  // Nuxt SEO 模块核心配置

  seo: {

    // 基础站点信息（会自动复用为 OG 基础信息）

    site: {

      // ...

    },

    // OG 标签全局配置（重点：ogImage）

    og: {

      // 全局默认 OG 类型

      type: "website",

      // 全局默认 OG Image 配置（核心）

      image: {

        // 图片路径：推荐用绝对路径，或相对路径（模块会自动拼接 site.url）

        src: "/og-default.jpg", // 等价于 https://你的域名.com/og-default.jpg

        width: 1200, // 最优尺寸

        height: 630,

        type: "image/jpeg", // 图片格式

        alt: "网站默认分享封面", // 图片描述（可选，提升可访问性）

      },

      // 全局默认语言

      locale: "zh_CN",

    },

    // 兼容 Twitter 卡片（可选，自动复用 ogImage）

    twitter: {

      card: "summary_large_image", // 大图卡片样式

    },

  },

})

单页面配置

单页面配置的内容会覆盖全局配置。

在具体页面（如 pages/article/[id].vue）中，用 useOgImage 或 useSeoMeta 自定义该页面的 OG Image：

<template>

  <div>详情页</div>

</template>



<script setup lang="ts">

  // 1. 假设从接口获取文章数据

  const article = await fetchArticleData() // 你的业务逻辑

  const articleCover = article.coverImage || "/og-article-default.jpg"



  // 2. 方式1：单独修改 OG Image（推荐，更精准）

  useOgImage({

    src: articleCover, // 自定义封面图路径

    width: 1200,

    height: 630,

    alt: article.title, // 用文章标题作为图片描述

  })



  // 3. 方式2：批量修改 OG 信息（含 Image）

  useSeoMeta({

    ogTitle: article.title, // 文章标题

    ogDescription: article.summary, // 文章摘要

    ogImage: [

      {

        src: articleCover,

        width: 1200,

        height: 630,

      },

    ],

    twitterImage: articleCover, // 兼容 Twitter

  })

</script>

动态路由批量配置

动态页面的配置可以结合sitemap来设置：

// nuxt.config.ts

export default defineNuxtConfig({

  modules: ["@nuxtjs/seo"],

  sitemap: {

    // 动态生成路由 + 对应 OG Image

    routes: async () => {

      const articles = await fetchAllArticles() // 获取所有文章

      return articles.map((article) => ({

        url: `/article/${article.id}`,

        // 给每个路由绑定 OG Image

        seo: {

          ogImage: {

            src: article.coverImage,

            width: 1200,

            height: 630,

          },

        },

      }))

    },

  },

})

如何验证配置是否生效？

启动项目，访问页面右键「页面源代码」，能看到 <meta property="og:image" content="你的图片URL"> 即配置成功。

SEO 进阶技巧与最佳实践

1. 喂饱搜索引擎

搜索引擎喜欢结构化数据。通过 Schema.org 标记，你可以让 Google 更精准地理解你的内容。

Nuxt SEO 提供了 useSchemaOrg 组合式函数，让你可以像写 Vue 组件一样编写 Schema：

<script setup lang="ts">

  useSchemaOrg([

    defineArticle({

      image: '/images/cover.jpg',

      datePublished: '2026-02-18',

      author: {

        name: 'Trae',

      },

    })

  ])

</script>

2. 社交分享优化

当用户将你的链接分享到 Twitter 或微信时，一张精美的预览图能显著提高点击率。

• Open Graph 标签：自动生成 og:title, og:description 等标签。


• OG Image 生成：nuxt-og-image 模块可以根据你的页面内容（标题、摘要）动态生成 SVG 或 PNG 图片。这意味着你不需要为每篇文章手动通过 Photoshop 制作封面，代码即设计！

3. 链接与 URL 规范化

重复内容是 SEO 的大忌。Nuxt SEO 能帮你处理这些细节：

• Trailing Slashes：统一 URL 结尾是否带斜杠（例如 /about vs /about/），避免被视为两个页面。


• Canonical URLs：自动添加规范链接，告诉搜索引擎哪个是"正版"页面，防止参数（如 ?utm_source=...）导致权重分散。

多搜索引擎适配策略

不同的搜索引擎有不同的脾气，针对国内外的搜索巨头，可以采取差异化的策略。

Google 优化

Google 的爬虫能力最强，能够很好地执行 JavaScript。

• Core Web Vitals：重点关注 LCP (最大内容绘制)、CLS (累积布局偏移) 和 INP (交互到下一次绘制)。Nuxt 默认的性能优化通常能满足要求。


• Google Search Console：在 GSC 中主动提交你的 sitemap.xml，并定期查看"覆盖率"报告，修复 404 和 500 错误。


• 富媒体搜索结果：利用上文提到的 Schema 标记，争取在搜索结果中展示星级评分、问答等富媒体信息。

百度优化

百度爬虫对现代 JavaScript 的执行能力相对较弱，且对页面加载速度极其敏感。

• 确保 SSR 输出：这是最关键的一点。确保你的 Nuxt 应用以 SSR 模式运行，并且 HTML 源码中直接包含核心内容。
  
  
  
  
  • 验证方法：在终端运行 curl https://your-site.com，检查返回的 HTML 是否包含你的内容。
  
  
  
  


• 主动推送：百度非常依赖主动提交。看在网站上线后，通过 API 立即将链接推送到百度站长平台。


• URL 结构：百度更喜欢扁平、简单的 URL 结构，避免过深的层级和复杂的动态参数。


• 移动端适配：百度对移动端友好的站点有明显的加权，做好响应式适配移动端是一个不错的选择。

必应优化

Bing 在搜索端的占比越来越高，且是 ChatGPT 搜索的数据源之一。

• IndexNow 协议：Bing 大力推广 IndexNow 协议，允许网站在一个 URL 发生变化时立即通知搜索引擎。这比传统的 Sitemap 被动抓取要快得多。


• Bing Webmaster Tools：功能与 GSC 类似，建议注册并提交 Sitemap。

总结

SEO 是一个长期积累的过程，但 Nuxt SEO 模块帮我们扫清了技术障碍。通过合理的配置和使用，并针对 Google、百度等不同平台进行针对性优化，可以确保你的 Nuxt 应用在起跑线上就领先一步。

🔗 项目地址: nuxtseo.com

👍作品推荐

Haotab 新标签页，一个优雅的新标签页

chrome 商店
| edge 商店
| 在线版

❤️静待你的体验

最近，一篇关于“2028年全球智能危机”的预测在硅谷和打工人的朋友圈里疯传。

很多朋友和同事都在狂转这篇充满洞见的报告，看完这篇报告，很多白领的第一反应恐怕是：

你妹的，赶紧把电脑咋了回家种地吧！白领不存在了。

• 广告传媒不存在了


• IT互联网不存在了


• 传统软件行业不存在了
  
  ……

震撼程度堪比物理学家被智子扰乱道心。

让我们看看这篇文章的原文长啥样：

核心观点：短期经济会增长，但其实是假象。因为大部分人没有受益，因此消费会受到暴击，而且会陷入恶性循环。

补充观点：那些靠解决不方便小摩擦的生意会完全被AI取代。

以及他对就业形式的估计也是非常悲观的：

并且，他认为这些冲击之下，信贷危机会如约而至，大规模的个体违约将会发生。

如果再结合一下作者所在的国家——阿美，似乎可以预见到斩杀线的大量降临。

一些行业预测

这篇预测的核心恐吓点可以总结为“白领护城河的三大崩塌”：

• 软件服务商（SaaS）的末日： AI智能体（Agent）普及后，人人都能直接用自然语言写出专属软件，不再需要花大价钱购买企业服务。


• 互联网广告模式的黄昏： 当AI助手能瞬间帮你货比三家、找到全网最低价时，谁还会去点击那些充满套路的商业广告？靠流量收租的公司将面临绝境。


• 智力劳动贬值： 这是最让人破防的一点。曾经高高在上的办公室脑力工作，其门槛被AI彻底踏破，脑力劳动变得廉价。

失业的白领怎么办呢？

铁人三项，吉祥三宝，选择总之不多。

这也难怪，白领们看到这篇文章会如此惊吓，难怪有人会陷入虚无，怀疑AI究竟是造福全人类，还是仅仅变成了资本家敛财、让普通人失业的机器 。

以史为镜

但如果我们跳出眼前的困境，把目光延申像更远的时光，看到远古时期。

• 奴隶时代的农业大发展之后：牛马和铁器大规模替代纯人力时，种地的人并没有消失。生产关系的变革让他们从任人宰割的农奴变成了农民。
  
  

  
  

  你看，生产力的极大发展反而给了底层人民尊严。

  
  

  
  

• 第一次工业革命后：蒸汽机确实砸碎了传统纺织工人的饭碗，但它催生了现代服装工业。今天，围绕着服装不仅有工厂，更衍生出了电商投流、短视频打爆款等庞大的产业链 。

• 通信时代的“电报员下岗”： 电报员消失了，但随后诞生了庞大的电信运营商网络；纸媒衰落了，却迎来了自媒体和博主百花齐放的时代。

核心定律在于：工具的每一次史诗级升级，可能确实伴随着某些职业和岗位的消失，但都有更多的岗位应运而生。

AI 时代的新职业会是什么？

如果一位程序员跑去100年前的1926年，让当时民国年轻人畅想这位程序员的职位。

他可能猜错1000次，也想象不到神州大地上会有这么大一批人在面对着键盘写代码。

别急着给人类的岗位下死刑。

可能只是局限于人类当前的认知和时代局限，暂时无法想象出那些我们还未见识过的职业。

更宏观地看，我们现在定义的“打卡上班”，也许只是人类漫长历史中的一个过渡状态 。当生产力真的极大丰富时，未知虽然代表着恐惧，但也同样蕴含着无限重塑的可能。

同学们好，我是 Eugene（尤金），一个拥有多年中后台开发经验的前端工程师~

（Eugene 发音很简单，/juːˈdʒiːn/，大家怎么顺口怎么叫就好）

你是否也有过：明明学过很多技术，一到关键时候却讲不出来、甚至写不出来？

你是否也曾怀疑自己，是不是太笨了，明明感觉会，却总差一口气？

就算想沉下心从头梳理，可工作那么忙，回家还要陪伴家人。

一天只有24小时，时间永远不够用，常常感到力不从心。

技术行业，本就是逆水行舟，不进则退。

如果你也有同样的困扰，别慌。

从现在开始，跟着我一起心态归零，利用碎片时间，来一次彻彻底底的基础扫盲。

这一次，我们一起慢慢来，扎扎实实变强。

不搞花里胡哨的理论堆砌，只分享看得懂、用得上的前端干货，

咱们一起稳步积累，真正摆脱“面向搜索引擎写代码”的尴尬。

1. 开篇：有库可用，为什么还要自己写？

lodash、ramda 等库已经提供这些工具函数，但在面试、基础补强、和「读懂库源码」的场景里，手写一遍很有价值：

• 搞清概念：什么算「深拷贝」、什么算「去重」


• 踩一遍坑：循环引用、NaN、Date、RegExp、Symbol 等


• 形成习惯：知道什么时候用浅拷贝、什么时候必须深拷贝

下面按「深拷贝 → 去重 → 扁平化」的顺序，每种都给出可直接用的实现和说明。

2. 深拷贝

2.1 浅拷贝 vs 深拷贝，怎么选？

一句话：只要会改到「嵌套对象/数组」，就考虑深拷贝。

2.2 常见坑

2.3 实现示例（含循环引用与特殊类型处理）

function deepClone(obj, cache = new WeakMap()) {

  // 1. 基本类型、null、函数 直接返回

  if (obj === null || typeof obj !== 'object') {

    return obj;

  }



  // 2. 循环引用：用 WeakMap 缓存已拷贝对象

  if (cache.has(obj)) {

    return cache.get(obj);

  }



  // 3. 特殊对象类型

  if (obj instanceof Date) return new Date(obj.getTime());

  if (obj instanceof RegExp) return new RegExp(obj.source, obj.flags);

  if (obj instanceof Map) {

    const mapCopy = new Map();

    cache.set(obj, mapCopy);

    obj.forEach((v, k) => mapCopy.set(deepClone(k, cache), deepClone(v, cache)));

    return mapCopy;

  }

  if (obj instanceof Set) {

    const setCopy = new Set();

    cache.set(obj, setCopy);

    obj.forEach(v => setCopy.add(deepClone(v, cache)));

    return setCopy;

  }



  // 4. 普通对象 / 数组

  const clone = Array.isArray(obj) ? [] : {};

  cache.set(obj, clone);



  // 包含 Symbol 作为 key

  const keys = [...Object.keys(obj), ...Object.getOwnPropertySymbols(obj)];

  keys.forEach(key => {

    clone[key] = deepClone(obj[key], cache);

  });



  return clone;

}



// 使用示例

const original = { a: 1, b: { c: 2 }, d: [3, 4] };

original.self = original; // 循环引用

const cloned = deepClone(original);

cloned.b.c = 999;

console.log(original.b.c); // 2，原对象未被修改

要点：WeakMap 解决循环引用，Date/RegExp/Map/Set 单独分支，Object.getOwnPropertySymbols 保证 Symbol key 不丢失。

3. 去重

3.1 场景与选型

3.2 几种实现

1）简单数组去重（含 NaN）

// 方式一：Set（ES6 最常用）

function uniqueBySet(arr) {

  return [...new Set(arr)];

}



// 方式二：filter + indexOf（兼容性更好，但 NaN 会出问题）

function uniqueByFilter(arr) {

  return arr.filter((item, index) => arr.indexOf(item) === index);

}



// 方式三：兼容 NaN 的版本

function unique(arr) {

  const result = [];

  const seenNaN = false; // 用 flag 标记是否已经加入过 NaN

  for (const item of arr) {

    if (item !== item) { // NaN !== NaN

      if (!seenNaN) {

        result.push(item);

        seenNaN = true; // 这里需要闭包，下面用修正版

      }

    } else if (!result.includes(item)) {

      result.push(item);

    }

  }

  return result;

}



// 修正：用变量

function uniqueWithNaN(arr) {

  const result = [];

  let hasNaN = false;

  for (const item of arr) {

    if (Number.isNaN(item)) {

      if (!hasNaN) {

        result.push(NaN);

        hasNaN = true;

      }

    } else if (!result.includes(item)) {

      result.push(item);

    }

  }

  return result;

}

注意：Set 本身对 NaN 是去重的（ES2015 规范），所以 [...new Set([1, NaN, 2, NaN])] 结果正确。需要兼容 NaN 的，多是旧环境或面试题场景。

2）对象数组按某字段去重

function uniqueByKey(arr, key) {

  const seen = new Map();

  return arr.filter(item => {

    const k = item[key];

    if (seen.has(k)) return false;

    seen.set(k, true);

    return true;

  });

}



// 使用

const users = [

  { id: 1, name: '张三' },

  { id: 2, name: '李四' },

  { id: 1, name: '张三2' }

];

console.log(uniqueByKey(users, 'id'));

// [{ id: 1, name: '张三' }, { id: 2, name: '李四' }]

4. 扁平化

4.1 场景

• 把 [1, [2, [3, 4]]] 变成 [1, 2, 3, 4]


• 有时候需要「只扁平一层」或「扁平到指定层数」

4.2 实现

1）递归全扁平

function flatten(arr) {

  const result = [];

  for (const item of arr) {

    if (Array.isArray(item)) {

      result.push(...flatten(item));

    } else {

      result.push(item);

    }

  }

  return result;

}



console.log(flatten([1, [2, [3, 4], 5]])); // [1, 2, 3, 4, 5]

2）指定深度扁平（如 Array.prototype.flat）

function flattenDepth(arr, depth = 1) {

  if (depth <= 0) return arr;



  const result = [];

  for (const item of arr) {

    if (Array.isArray(item) && depth > 0) {

      result.push(...flattenDepth(item, depth - 1));

    } else {

      result.push(item);

    }

  }

  return result;

}



console.log(flattenDepth([1, [2, [3, 4]]], 1)); // [1, 2, [3, 4]]

console.log(flattenDepth([1, [2, [3, 4]]], 2)); // [1, 2, 3, 4]

3）用 reduce 递归写法（另一种常见写法）

function flattenByReduce(arr) {

  return arr.reduce((acc, cur) => {

    return acc.concat(Array.isArray(cur) ? flattenByReduce(cur) : cur);

  }, []);

}

5. 小结：日常怎么选

自己写一遍的价值在于：搞清楚边界情况、循环引用、特殊类型，以后选库或读源码时心里有数。

学习本就是一场持久战，不需要急着一口吃成胖子。哪怕今天你只记住了一点点，这都是实打实的进步。

后续我还会继续用这种大白话、讲实战方式，带大家扫盲更多前端基础。

关注我，不迷路，咱们把那些曾经模糊的知识点，一个个彻底搞清楚。

如果你觉得这篇内容对你有帮助，不妨点赞收藏，下次写代码卡壳时，拿出来翻一翻，比搜引擎更靠谱。

我是 Eugene，你的电子学友，我们下一篇干货见～

什么是 JSBridge

JSBridge 是 WebView 中 JavaScript 与 Native 代码之间的通信桥梁。核心问题是：两个不同运行环境的代码如何互相调用？

通信原理

1. Native 调用 JS（简单）

WebView 本身就提供了执行 JS 的能力，原理很直接：WebView 控制着 JS 引擎，可以直接向其注入并执行代码。

// Android

webView.evaluateJavascript("window.appCallJS('data')", null);



// iOS

webView.evaluateJavaScript("window.appCallJS('data')")



// Flutter

webViewController.runJavaScript("window.appCallJS('data')");

2. JS 调用 Native（核心难点）

JS 运行在沙箱中，无法直接访问系统 API。有两种主流方案：

方案一：注入 API

Native 在 WebView 初始化时，向 JS 全局对象注入方法：

// Android - 注入对象到 window

webView.addJavascriptInterface(new Object() {

    @JavascriptInterface

    public void showToast(String msg) {

        Toast.makeText(context, msg, Toast.LENGTH_SHORT).show();

    }

}, "NativeBridge");

JS 端直接调用：

window.NativeBridge.showToast("Hello")

本质：Native 把自己的方法"挂"到了 JS 的全局作用域里。

方案二：URL Scheme 拦截

JS 发起一个特殊协议的请求，Native 拦截并解析：

// JS 端

location.href = 'jsbridge://showToast?msg=Hello'



// 或使用 iframe（避免页面跳转）

const iframe = document.createElement('iframe')

iframe.src = 'jsbridge://showToast?msg=Hello'

document.body.appendChild(iframe)

// Android 端拦截

webView.setWebViewClient(new WebViewClient() {

    @Override

    public boolean shouldOverrideUrlLoading(WebView view, String url) {

        if (url.startsWith("jsbridge://")) {

            // 解析 url，执行对应 Native 方法

            return true;

        }

        return false;

    }

});

本质：利用 WebView 的 URL 加载机制作为通信通道。

异步回调的实现

JS 调用 Native 后如何拿到返回值？通过回调 ID 机制：

// JS 端

let callbackId = 0

const callbacks = {}



function callNative(method, params) {

    return new Promise((resolve) => {

        const id = callbackId++

        callbacks[id] = resolve

        // 告诉 Native：调用完成后，用这个 id 回调我

        window.NativeBridge.invoke(JSON.stringify({

            method,

            params,

            callbackId: id

        }))

    })

}



// Native 执行完后调用这个函数

window.handleCallback = (id, result) => {

    callbacks[id]?.(result)

    delete callbacks[id]

}

流程：JS 调用 → Native 处理 → Native 调用 evaluateJavascript 执行回调函数 → JS 收到结果

各平台注入对象命名

Android 示例

// 第二个参数就是 JS 中的对象名，可以随便取

webView.addJavascriptInterface(bridgeObject, "MyBridge");

// JS 端

window.MyBridge.method()

iOS 示例

// name 就是 JS 中的 handler 名

configuration.userContentController.add(self, name: "iOSBridge")

// JS 端

window.webkit.messageHandlers.iOSBridge.postMessage(data)

Flutter (flutter_inappwebview) 示例

// Flutter 端注册 handler，handlerName 可自定义

webViewController.addJavaScriptHandler(

  handlerName: 'myCustomHandler',

  callback: (args) { ... }

);

// JS 端，flutter_inappwebview 是固定的

window.flutter_inappwebview.callHandler('myCustomHandler', data)

通信方式总结

常见通信方式对比

最佳实践建议

同学们好，我是 Eugene（尤金），一个拥有多年中后台开发经验的前端工程师~

（Eugene 发音很简单，/juːˈdʒiːn/，大家怎么顺口怎么叫就好）

你是否也有过：明明学过很多技术，一到关键时候却讲不出来、甚至写不出来？

你是否也曾怀疑自己，是不是太笨了，明明感觉会，却总差一口气？

就算想沉下心从头梳理，可工作那么忙，回家还要陪伴家人。

一天只有24小时，时间永远不够用，常常感到力不从心。

技术行业，本就是逆水行舟，不进则退。

如果你也有同样的困扰，别慌。

从现在开始，跟着我一起心态归零，利用碎片时间，来一次彻彻底底的基础扫盲。

这一次，我们一起慢慢来，扎扎实实变强。

不搞花里胡哨的理论堆砌，只分享看得懂、用得上的前端干货，

咱们一起稳步积累，真正摆脱“面向搜索引擎写代码”的尴尬。

1. 开篇：有库可用，为什么还要自己写？

lodash、ramda 等库已经提供这些工具函数，但在面试、基础补强、和「读懂库源码」的场景里，手写一遍很有价值：

• 搞清概念：什么算「深拷贝」、什么算「去重」


• 踩一遍坑：循环引用、NaN、Date、RegExp、Symbol 等


• 形成习惯：知道什么时候用浅拷贝、什么时候必须深拷贝

下面按「深拷贝 → 去重 → 扁平化」的顺序，每种都给出可直接用的实现和说明。

2. 深拷贝

2.1 浅拷贝 vs 深拷贝，怎么选？

一句话：只要会改到「嵌套对象/数组」，就考虑深拷贝。

2.2 常见坑

2.3 实现示例（含循环引用与特殊类型处理）

function deepClone(obj, cache = new WeakMap()) {

  // 1. 基本类型、null、函数 直接返回

  if (obj === null || typeof obj !== 'object') {

    return obj;

  }



  // 2. 循环引用：用 WeakMap 缓存已拷贝对象

  if (cache.has(obj)) {

    return cache.get(obj);

  }



  // 3. 特殊对象类型

  if (obj instanceof Date) return new Date(obj.getTime());

  if (obj instanceof RegExp) return new RegExp(obj.source, obj.flags);

  if (obj instanceof Map) {

    const mapCopy = new Map();

    cache.set(obj, mapCopy);

    obj.forEach((v, k) => mapCopy.set(deepClone(k, cache), deepClone(v, cache)));

    return mapCopy;

  }

  if (obj instanceof Set) {

    const setCopy = new Set();

    cache.set(obj, setCopy);

    obj.forEach(v => setCopy.add(deepClone(v, cache)));

    return setCopy;

  }



  // 4. 普通对象 / 数组

  const clone = Array.isArray(obj) ? [] : {};

  cache.set(obj, clone);



  // 包含 Symbol 作为 key

  const keys = [...Object.keys(obj), ...Object.getOwnPropertySymbols(obj)];

  keys.forEach(key => {

    clone[key] = deepClone(obj[key], cache);

  });



  return clone;

}



// 使用示例

const original = { a: 1, b: { c: 2 }, d: [3, 4] };

original.self = original; // 循环引用

const cloned = deepClone(original);

cloned.b.c = 999;

console.log(original.b.c); // 2，原对象未被修改

要点：WeakMap 解决循环引用，Date/RegExp/Map/Set 单独分支，Object.getOwnPropertySymbols 保证 Symbol key 不丢失。

3. 去重

3.1 场景与选型

3.2 几种实现

1）简单数组去重（含 NaN）

// 方式一：Set（ES6 最常用）

function uniqueBySet(arr) {

  return [...new Set(arr)];

}



// 方式二：filter + indexOf（兼容性更好，但 NaN 会出问题）

function uniqueByFilter(arr) {

  return arr.filter((item, index) => arr.indexOf(item) === index);

}



// 方式三：兼容 NaN 的版本

function unique(arr) {

  const result = [];

  const seenNaN = false; // 用 flag 标记是否已经加入过 NaN

  for (const item of arr) {

    if (item !== item) { // NaN !== NaN

      if (!seenNaN) {

        result.push(item);

        seenNaN = true; // 这里需要闭包，下面用修正版

      }

    } else if (!result.includes(item)) {

      result.push(item);

    }

  }

  return result;

}



// 修正：用变量

function uniqueWithNaN(arr) {

  const result = [];

  let hasNaN = false;

  for (const item of arr) {

    if (Number.isNaN(item)) {

      if (!hasNaN) {

        result.push(NaN);

        hasNaN = true;

      }

    } else if (!result.includes(item)) {

      result.push(item);

    }

  }

  return result;

}

注意：Set 本身对 NaN 是去重的（ES2015 规范），所以 [...new Set([1, NaN, 2, NaN])] 结果正确。需要兼容 NaN 的，多是旧环境或面试题场景。

2）对象数组按某字段去重

function uniqueByKey(arr, key) {

  const seen = new Map();

  return arr.filter(item => {

    const k = item[key];

    if (seen.has(k)) return false;

    seen.set(k, true);

    return true;

  });

}



// 使用

const users = [

  { id: 1, name: '张三' },

  { id: 2, name: '李四' },

  { id: 1, name: '张三2' }

];

console.log(uniqueByKey(users, 'id'));

// [{ id: 1, name: '张三' }, { id: 2, name: '李四' }]

4. 扁平化

4.1 场景

• 把 [1, [2, [3, 4]]] 变成 [1, 2, 3, 4]


• 有时候需要「只扁平一层」或「扁平到指定层数」

4.2 实现

1）递归全扁平

function flatten(arr) {

  const result = [];

  for (const item of arr) {

    if (Array.isArray(item)) {

      result.push(...flatten(item));

    } else {

      result.push(item);

    }

  }

  return result;

}



console.log(flatten([1, [2, [3, 4], 5]])); // [1, 2, 3, 4, 5]

2）指定深度扁平（如 Array.prototype.flat）

function flattenDepth(arr, depth = 1) {

  if (depth <= 0) return arr;



  const result = [];

  for (const item of arr) {

    if (Array.isArray(item) && depth > 0) {

      result.push(...flattenDepth(item, depth - 1));

    } else {

      result.push(item);

    }

  }

  return result;

}



console.log(flattenDepth([1, [2, [3, 4]]], 1)); // [1, 2, [3, 4]]

console.log(flattenDepth([1, [2, [3, 4]]], 2)); // [1, 2, 3, 4]

3）用 reduce 递归写法（另一种常见写法）

function flattenByReduce(arr) {

  return arr.reduce((acc, cur) => {

    return acc.concat(Array.isArray(cur) ? flattenByReduce(cur) : cur);

  }, []);

}

5. 小结：日常怎么选

自己写一遍的价值在于：搞清楚边界情况、循环引用、特殊类型，以后选库或读源码时心里有数。

学习本就是一场持久战，不需要急着一口吃成胖子。哪怕今天你只记住了一点点，这都是实打实的进步。

后续我还会继续用这种大白话、讲实战方式，带大家扫盲更多前端基础。

关注我，不迷路，咱们把那些曾经模糊的知识点，一个个彻底搞清楚。

如果你觉得这篇内容对你有帮助，不妨点赞收藏，下次写代码卡壳时，拿出来翻一翻，比搜引擎更靠谱。

我是 Eugene，你的电子学友，我们下一篇干货见～

大家好，我是小悟。

• 想象一下你去游乐园，买了一张通票（登录），然后就可以玩所有项目（访问各个系统），不用每个项目都重新买票（重新登录）。这就是单点登录（SSO）的精髓！
  
  

  SSO的日常比喻

  
  
  
  
  • 普通登录：像去不同商场，每个都要查会员卡
  
  
  • 单点登录：像微信扫码登录，一扫全搞定
  
  
  • 令牌：像游乐园手环，戴着就能证明你买过票
  
  
  
  

  下面用代码来实现这个"游乐园通票系统"：

  
  

  代码实现：简易SSO系统

  
  

  import java.util.*;
  
  
  
  // 用户类 - 就是我们这些想玩项目的游客
  
  class User {
  
      private String username;
  
      private String password;
  
      
  
      public User(String username, String password) {
  
          this.username = username;
  
          this.password = password;
  
      }
  
      
  
      // getters 省略...
  
  }
  
  
  
  // 令牌类 - 游乐园手环
  
  class Token {
  
      private String tokenId;
  
      private String username;
  
      private Date expireTime;
  
      
  
      public Token(String username) {
  
          this.tokenId = UUID.randomUUID().toString();
  
          this.username = username;
  
          // 令牌1小时后过期 - 游乐园晚上要关门的！
  
          this.expireTime = new Date(System.currentTimeMillis() + 3600 * 1000);
  
      }
  
      
  
      public boolean isValid() {
  
          return new Date().before(expireTime);
  
      }
  
      
  
      // getters 省略...
  
  }
  
  
  
  // SSO认证中心 - 游乐园售票处
  
  class SSOAuthCenter {
  
      private Map<String, Token> validTokens = new HashMap<>();
  
      private Map<String, User> users = new HashMap<>();
  
      
  
      public SSOAuthCenter() {
  
          // 预先注册几个用户 - 办了年卡的游客
  
          users.put("zhangsan", new User("zhangsan", "123456"));
  
          users.put("lisi", new User("lisi", "abcdef"));
  
      }
  
      
  
      // 登录 - 买票入场
  
      public String login(String username, String password) {
  
          User user = users.get(username);
  
          if (user != null && user.getPassword().equals(password)) {
  
              Token token = new Token(username);
  
              validTokens.put(token.getTokenId(), token);
  
              System.out.println(username + " 登录成功！拿到游乐园手环：" + token.getTokenId());
  
              return token.getTokenId();
  
          }
  
          System.out.println("用户名或密码错误！请重新买票！");
  
          return null;
  
      }
  
      
  
      // 验证令牌 - 检查手环是否有效
  
      public boolean validateToken(String tokenId) {
  
          Token token = validTokens.get(tokenId);
  
          if (token != null && token.isValid()) {
  
              System.out.println("手环有效，欢迎继续玩耍！");
  
              return true;
  
          }
  
          System.out.println("手环无效或已过期，请重新登录！");
  
          validTokens.remove(tokenId); // 清理过期令牌
  
          return false;
  
      }
  
      
  
      // 登出 - 离开游乐园
  
      public void logout(String tokenId) {
  
          validTokens.remove(tokenId);
  
          System.out.println("已登出，欢迎下次再来玩！");
  
      }
  
  }
  
  
  
  // 业务系统A - 过山车
  
  class SystemA {
  
      private SSOAuthCenter authCenter;
  
      
  
      public SystemA(SSOAuthCenter authCenter) {
  
          this.authCenter = authCenter;
  
      }
  
      
  
      public void accessSystem(String tokenId) {
  
          System.out.println("=== 欢迎来到过山车 ===");
  
          if (authCenter.validateToken(tokenId)) {
  
              System.out.println("过山车启动！尖叫声在哪里！");
  
          } else {
  
              System.out.println("请先登录再玩过山车！");
  
          }
  
      }
  
  }
  
  
  
  // 业务系统B - 旋转木马
  
  class SystemB {
  
      private SSOAuthCenter authCenter;
  
      
  
      public SystemB(SSOAuthCenter authCenter) {
  
          this.authCenter = authCenter;
  
      }
  
      
  
      public void accessSystem(String tokenId) {
  
          System.out.println("=== 欢迎来到旋转木马 ===");
  
          if (authCenter.validateToken(tokenId)) {
  
              System.out.println("木马转起来啦！找回童年记忆！");
  
          } else {
  
              System.out.println("请先登录再玩旋转木马！");
  
          }
  
      }
  
  }
  
  
  
  // 测试我们的SSO系统
  
  public class SSODemo {
  
      public static void main(String[] args) {
  
          // 创建认证中心 - 游乐园大门
  
          SSOAuthCenter authCenter = new SSOAuthCenter();
  
          
  
          // 张三登录
  
          String token = authCenter.login("zhangsan", "123456");
  
          
  
          if (token != null) {
  
              // 拿着同一个令牌玩不同项目
  
              SystemA systemA = new SystemA(authCenter);
  
              SystemB systemB = new SystemB(authCenter);
  
              
  
              systemA.accessSystem(token);  // 玩过山车
  
              systemB.accessSystem(token);  // 玩旋转木马
  
              
  
              // 登出
  
              authCenter.logout(token);
  
              
  
              // 再尝试访问 - 应该被拒绝
  
              systemA.accessSystem(token);
  
          }
  
          
  
          // 测试错误密码
  
          authCenter.login("lisi", "wrongpassword");
  
      }
  
  }
  
  

  
  

  运行结果示例：

  
  

  zhangsan 登录成功！拿到游乐园手环：a1b2c3d4-e5f6-7890-abcd-ef1234567890
  
  === 欢迎来到过山车 ===
  
  手环有效，欢迎继续玩耍！
  
  过山车启动！尖叫声在哪里！
  
  === 欢迎来到旋转木马 ===
  
  手环有效，欢迎继续玩耍！
  
  木马转起来啦！找回童年记忆！
  
  已登出，欢迎下次再来玩！
  
  === 欢迎来到过山车 ===
  
  手环无效或已过期，请重新登录！
  
  请先登录再玩过山车！
  
  用户名或密码错误！请重新买票！
  
  

  
  

  总结一下：

  
  

  单点登录就像：

  
  
  
  
  • 一次认证，处处通行 🎫
  
  
  • 不用重复输入密码 🔑
  
  
  • 安全又方便 👍
  
  
  
  

  好的SSO系统就像好的游乐园管理，既要让游客玩得开心，又要确保安全！

谢谢你看我的文章，既然看到这里了，如果觉得不错，随手点个赞、转发、在看三连吧，感谢感谢。那我们，下次再见。

您的一键三连，是我更新的最大动力，谢谢

山水有相逢，来日皆可期，谢谢阅读，我们再会

我手中的金箍棒，上能通天，下能探海

一、事件回顾

近期，所有群小伙伴都在分享元宝，铺天盖地的现金红包，如下：

终于在今天，2月4日，微信安全中心发布公告，对腾讯元宝的春节红包活动进行处置——限制其在微信内直接打开。

理由？诱导分享。

根据公告，元宝红包活动通过"做任务""领红包"等方式，诱导用户高频分享链接到微信群等场景，干扰平台生态秩序、影响用户体验。

这还不是最离谱的。

最离谱的是什么？

元宝是腾讯的产品，微信也是腾讯的产品。

相当于腾讯用左手扇了右手一巴掌，然后说："你违规了。"

二、魔幻现实

我们来还原一下这个离谱的场景：

微信（对元宝说）："根据《微信外部链接内容管理规范》第2.1.2条，你通过利益诱惑诱导用户分享外链，属于诱导分享违规。"

元宝（委屈）："可我是亲生的啊……"

微信（铁面无私）："亲生的怎么了？规则面前人人平等。"

好家伙，这波操作我愿称之为：

"大义灭亲" ✅

"六亲不认" ✅

"铁面无私" ✅

三、双标现场

更有意思的是，腾讯内部信中还试图挣扎：

"元宝春节红包活动在设计上，其基础逻辑是'无门槛领取'。用户无需完成诸如助力、集卡等任务，即可直接领取基础红包。与平台一贯反对的'诱导分享'模式有区别。"

翻译一下就是：

"我们这个不一样，用户不分享也能领红包。"

但问题是——

用户不分享，只能领基础红包；用户分享了，能领更多。

这叫什么？

这叫"不叫诱导分享，叫诱导你主动选择分享"。

跟"我不偷钱，我只是帮你保管"有什么区别？

四、讽刺拉满

整个事件最讽刺的是什么？

微信打击诱导分享，理由是"干扰平台生态秩序、影响用户体验、对用户造成骚扰"。

结果呢？

元宝红包活动在多个社交平台上刷屏，被网友质疑"诱导分享"。

然后微信不得不处罚自己的产品。

这叫什么？

搬起石头砸自己的脚。

不对。

这叫用石头砸自己的脚，然后说"看，我执行规则很严格"。

五、谁更受伤？

这个事件里，没有赢家。

元宝 → 活动被封，声誉受损？

微信 → 被网友群嘲"双标""自己打自己"

腾讯 → 内部互殴，家丑外扬

用户 → 本来能领红包，现在只能领个寂寞

四输。

六、写在最后

其实吧，这事儿要是换个角度看，也算是一件好事。

至少说明微信是认真执行规则的？。至于内部怎么协调，那是他们的事。

哪怕是亲儿子，该罚还是罚。过几天我就可以名正言顺的屏蔽其他不相关链接了，

但有一说一，下次做活动之前，能不能先内部对齐一下？

别闹到最后，自己把自己给处罚了。

怪尴尬的。各位当个乐看吧！

七、还有后续？

正当我以为这件事已经足够魔幻的时候，2月6日，更魔幻的事情发生了。

阿里千问正式上线"春节30亿免单"，发放奶茶免单卡。

结果呢？

千问的红包分享链接，也被微信屏蔽了。

页面显示："网页存在诱导或误导下载/跳转的内容，需要跳转第三方浏览器访问。"

好家伙，原来这不是"针对腾讯自家产品"的骚操作。

这是 "一视同仁"——不管你是腾讯的，还是阿里百度的，统统屏蔽。

发生了什么？

让我们来捋一捋时间线：

• 2月4日：微信处罚腾讯元宝，理由是"诱导分享"


• 2月6日：阿里千问上线春节免单活动，分享链接被微信屏蔽


• 同时，百度文心助手也因为该原因被封杀过