小菜鸟

EasyExcel钩子（Handler）机制：深度定制 Excel 写入过程

EasyExcel 作为高效的 Excel 处理框架，不仅提供了简单的读写 API，还通过钩子机制（Handler） 允许开发者在 Excel 写入的关键节点（如 Workbook 创建、Sheet 初始化、行 / 单元格生成等）插入自定义逻辑。本文将详细解析 EasyExcel 中的四大钩子接口（Workbook、Sheet、Row、Cell），并通过实例演示如何利用钩子实现复杂需求（如自定义样式、数据校验、动态调整结构等）。

钩子机制的核心作用

钩子机制（Handler）是 EasyExcel 提供的扩展点，允许开发者在 Excel 写入的生命周期节点中嵌入自定义代码，实现以下功能：

• 自定义样式（如表头加粗、奇数行变色、特定单元格高亮）；
• 数据校验（如单元格值超出范围时报错或自动修正）；
• 动态调整结构（如根据数据内容新增列、合并单元格）；
• 资源管理（如在 Workbook 关闭后释放临时资源）。

EasyExcel 将写入过程划分为四个层级的生命周期，对应四类钩子接口，层级关系如下：

1

Workbook（工作簿） → Sheet（工作表） → Row（行） → Cell（单元格）  

四大钩子接口详解

WorkbookWriteHandler：工作簿级钩子

作用于整个 Excel 工作簿的创建前后及销毁阶段，用于全局配置（如设置工作簿属性、加密文件等）。

核心方法

SheetWriteHandler：工作表级钩子

作用于单个 Sheet 的创建前后，用于配置 Sheet 特性（如设置默认列宽、隐藏 Sheet 等）。

核心方法

RowWriteHandler：行级钩子

作用于行的创建前后及销毁阶段，用于行级定制（如行高调整、行样式统一等）。

核心方法

CellWriteHandler：单元格级钩子

作用于单元格的创建、数据转换及销毁阶段，是最常用的钩子，用于单元格样式、数据处理等细节定制。

核心方法

实战：自定义钩子实现复杂需求

以下通过三个典型案例，演示如何使用钩子接口解决实际问题。

案例 1：表头样式定制（使用 CellWriteHandler）

需求：表头文字加粗、背景色设为浅灰色，对齐方式居中。

Maven 上传项目至中央仓库：从申请到发布的完整指南

将自己开发的工具包上传至 Maven 中央仓库，能让全球开发者通过简单的依赖坐标直接使用，是开源贡献的重要一步。本文基于 Sonatype OSSRH（Open Source Software Repository Hosting）平台，详细讲解从账号注册到最终发布的全流程。

准备工作

必要条件

• 一个公开的代码仓库（如 GitHub、Gitee），用于托管项目源码。
• 一个可验证的域名（如个人域名或代码平台域名，用于 GroupId 验证）。
• 安装 GPG（用于对发布文件进行签名，确保完整性）。

环境配置

• GPG 安装：

  • Windows：使用 Gpg4win。
  • Mac：使用 GPG Suite。
  • Linux：通过包管理器安装（如 sudo apt install gnupg）。

• 生成 GPG 密钥：
  打开终端执行以下命令，按提示输入姓名、邮箱和密码：

  1	gpg --full-generate-key

  生成后，上传公钥至公共服务器（确保 Maven 能验证签名）：

  1	gpg --keyserver hkp://keyserver.ubuntu.com:80 --send-keys 你的密钥ID

  （密钥 ID 可通过 gpg --list-keys 查看，格式为 8 位十六进制数）

Sonatype 账号与项目申请

Maven 中央仓库通过 Sonatype OSSRH 管理开源项目，需先注册并申请项目托管。

注册 Sonatype 账号

访问 Sonatype JIRA 注册账号，填写用户名、邮箱等信息（建议使用常用邮箱，后续验证需要）。

注册地址：https://issues.sonatype.org/secure/Signup!default.jspa

创建项目发布申请（New Issue）

1. 登录后点击 Create 按钮，选择：

   • Project：Community Support - Open Source Project Repository Hosting
   • Issue Type：New Project

2. 填写申请信息：

   • Summary：项目名称（如 tools-java: 通用工具类库）。
   • Group Id：项目的 Maven GroupId（关键！需验证所有权）。
     • 若有个人域名（如 example.com），可设为 com.example。
     • 若无域名，使用代码托管平台域名（如 Gitee 项目 gitee.com/yourname/tools-java，则 GroupId 为 io.gitee.yourname）。
   • Project URL：项目源码地址（如 https://gitee.com/yourname/tools-java）。
   • SCM URL：源码仓库地址（如 https://gitee.com/yourname/tools-java.git）。
   • Other Details：简要描述项目功能。

   

提交完成之后，会创建一个Issues

验证 GroupId 所有权

提交申请后，Sonatype 工作人员会在 1-2 个工作日内回复，要求验证 GroupId 所有权：

Maven 生成 Javadoc 文档出错：原因与解决方案

使用 maven-javadoc-plugin 生成 Javadoc 时，经常会因注释不规范导致构建失败（如缺少参数说明、标签格式错误）。本文将详解错误原因，并提供多种解决方案，帮助顺利生成文档。

错误原因分析

Javadoc 工具对注释规范性要求严格，常见错误包括：

• @param/@return/@throws 标签缺失或与实际参数不匹配。
• 注释中使用未闭合的 HTML 标签（如 <p> 未闭合）。
• 特殊字符未转义（如 & 需写成 &）。
• 方法 / 类注释为空但使用了 Javadoc 格式（/** ... */）。

当 maven-javadoc-plugin 检测到这些问题时，会默认将警告视为错误，导致构建失败（如 Exit code: 1）。

解决方案

1. 忽略注释检查（快速解决）

通过配置 doclint 参数禁用 Javadoc 的语法检查，忽略所有注释不规范的警告：

解决 Java 中的 Illegal key size 异常

当使用 Cipher.init() 方法时遇到 java.security.InvalidKeyException: Illegal key size 异常，通常是由于 Java 加密扩展（JCE）的默认策略限制了加密算法的密钥长度。

1
2
3
4
5
6
7

java.security.InvalidKeyException: Illegal key size
        at javax.crypto.Cipher.checkCryptoPerm(Cipher.java:1039)
        at javax.crypto.Cipher.implInit(Cipher.java:805)
        at javax.crypto.Cipher.chooseProvider(Cipher.java:864)
        at javax.crypto.Cipher.init(Cipher.java:1396)
        at javax.crypto.Cipher.init(Cipher.java:1327)

以下是详细的解决方案和背景说明：

异常原因

Java 安装时默认包含的 JCE 权限策略文件（local_policy.jar 和 US_export_policy.jar）受限于加密出口管制，对部分加密算法的密钥长度做了限制（如 AES 密钥默认最大支持 128 位）。当使用更长的密钥（如 192 位、256 位）时，就会触发此异常。

解决方案

针对 JDK 7 / JDK 8（低于 8u161 版本）

需要手动替换 JCE 无限制权限策略文件：

• 步骤 1：下载无限制策略文件
  根据 JDK 版本下载对应文件：
  • JDK 7：Oracle 官方下载
  • JDK 8：Oracle 官方下载
• 步骤 2：替换策略文件
  1. 解压下载的压缩包，得到 local_policy.jar 和 US_export_policy.jar。
  2. 找到 JDK 安装目录下的安全策略文件夹：
     • 路径：${JAVA_HOME}/jre/lib/security（注意区分 JDK 和 JRE 目录，需替换 JDK 内置 JRE 的文件）。
  3. 备份原有文件（可选），将下载的两个 JAR 文件复制到该目录，覆盖原有文件。
• 步骤 3：重启应用
  替换后需重启 Java 应用，新策略才能生效。

Elasticsearch 数据迁移：基于快照（Snapshot）的完整方案

当 Elasticsearch 服务器更换位置或集群升级时，数据迁移是核心任务。快照（Snapshot）是官方推荐的迁移方式，通过将索引数据备份到共享存储，再在目标集群恢复，实现安全高效的数据迁移。本文详细讲解基于快照的迁移流程，包括源集群备份、目标集群恢复及关键注意事项。

迁移原理与优势

快照迁移的核心原理

• 快照（Snapshot）：将 Elasticsearch 索引的元数据、分片数据备份到指定存储（如本地文件系统、S3、HDFS 等）。
• 恢复（Restore）：在目标集群中读取快照文件，重建索引结构和数据。

优势

• 完整性：完整备份索引的所有数据（包括映射、设置、分片），无数据丢失风险。
• 灵活性：支持选择性备份 / 恢复指定索引，适合大规模集群。
• 低影响：备份过程为增量式（仅备份变更数据），对源集群性能影响小。

源服务器（旧集群）操作

准备备份目录

创建用于存储快照的本地目录，并授权 Elasticsearch 进程访问：

1
2
3
4
5

# 创建目录
mkdir -p /data/elasticsearch/backups
# 授权（假设 Elasticsearch 运行用户为 elasticsearch）
chown -R elasticsearch:elasticsearch /data/elasticsearch/backups
chmod 755 /data/elasticsearch/backups

配置快照仓库路径

修改 elasticsearch.yml，添加快照仓库的根目录配置：