Java集成MinIO对象存储：上传下载、预签名与分片实践-北京尧图网络

1. 为什么文件管理这件事值得单独拎出来做做过业务系统的朋友大概都有类似体会项目刚起步时图片、合同附件、导入导出的表格全都往服务器本地磁盘一丢/data/upload/一个目录走天下代码里写个File.save就完事。等到机器扩容、容器化部署、多实例负载均衡一上来你会发现用户头像在A节点能看到、在B节点就是404再往后要备份、要迁移、要做容量统计才意识到文件这一层其实早就该抽出来了。我这几年接手的系统里凡是需要长期跑、需要横向扩容的几乎都会把文件存储独立出去走对象存储的路子。而在自建对象存储的选型里MinIO是落地成本最低、和Java生态契合度又特别高的一个单二进制部署、兼容 S3 协议、有成熟的官方 SDK本地开发直接一个 docker 命令拉起来就能用。这套组合解决的核心问题就是把文件存哪里、怎么取、怎么管从业务代码里剥离出来变成一个稳定、可水平扩展的基础设施。这篇文章适合谁看如果你正在写一个带附件上传的 Java 服务发现本地磁盘方案开始撑不住了或者你听说过对象存储但一直没实操过不知道怎么在 Spring Boot 里把 MinIO 的初始化、上传、下载、分片、临时链接这些东西串起来又或者你已经能跑通 demo但线上被桶策略、大文件超时、流没关导致连接池耗尽这些坑坑过——那下面这些内容应该能省你不少调试时间。我会从整体设计思路讲起再拆核心细节、给出可直接复制的实操代码最后把我在实际项目里踩到的坑整理成排查表。需要提前说明文中所有涉及具体业务、公司、人员的场景都是基于常见实践做的抽象描述代码也是从通用做法里提炼的模板你按自己的项目替换参数即可。2. 整体设计Java 与 MinIO 的职责边界怎么划2.1 先想清楚对象存储和数据库各自该管什么很多人一开始就把文件对象直接当数据库记录用结果查个附件列表要遍历桶或者把二进制塞进数据库的 BLOB 字段这两种极端都不可取。我比较推荐的分工是这样的文件的元信息落数据库文件实体落 MinIO。元信息包括什么业务归属属于哪个订单、哪个用户、原始文件名、存储对象名objectName、大小、MIME 类型、内容摘要、上传时间、状态临时/正式/已删除。有了这层列表分页、按业务查询、软删除、审计都有据可依而 MinIO 那边只负责按 objectName 存取字节流。这样做的直接好处是迁移存储时只换 objectName 背后的桶数据库记录一行都不用动反过来清理数据也只查库不用去遍历桶里的对象。为什么不用 MinIO 的对象标签tag来承担业务属性因为标签查询能力有限、不适合复杂条件组合而且把业务逻辑耦合到存储层将来换实现就会很痛。存储层保持哑一点是长期可维护的关键。2.2 客户端选型官方 SDK 与 Spring 封装怎么选Java 侧操作 MinIO 有两条常见路线一是直接用官方minio-javaSDK自己封装一个工具类二是用社区或自研的 starter 做一层 Spring 风格的包装。我的建议是先用官方 SDK 把核心能力跑通再考虑要不要包一层。理由是官方 SDK 的 API 语义清晰MinioClient上的putObject、getObject、getPresignedObjectUrl都是一眼能懂的先理解原语后面封装才不会被层层抽象挡住视线。版本上要注意minio-java8.x 与 7.x 有不兼容变更8.x 之后引入了io.minio包下的 builder 风格 API。引入方式很简单dependency groupIdio.minio/groupId artifactIdminio/artifactId version8.5.7/version /dependency选择这个版本的考量是它对 S3 兼容接口的支持比较完整分片上传、预签名、桶策略这些我常用的能力都有而且依赖的 OkHttp 版本较新长连接复用表现稳定。7.x 不是不能用但新项目没有理由停在旧版本上纠结。另一个容易被忽略的点是客户端必须单例复用。MinioClient内部持有一个 OkHttp 的连接池如果你每次请求都new MinioClient(...)连接池就形同虚设压测时空闲连接和 TIME_WAIT 会一起爆掉。我见过一个项目在 Service 方法里每次 newQPS 上到两百就开始偶发超时改成注入单例后直接恢复。2.3 桶的规划按环境分还是按业务分桶bucket是 MinIO 里的顶层隔离单元命名规则和 DNS 类似只能小写字母、数字、连字符长度 3 到 63。规划时我一般遵循两条原则按环境隔离app-dev、app-test、app-prod分开避免测试数据污染生产也方便不同环境的权限收口。按访问策略分而不是按业务表分。业务模块再细分其实用一个桶加 objectName 的前缀如contract/2024/06/xxx.pdf就够了。桶的数量增多会带来策略维护成本而对查询性能没什么帮助。注意不要把是否需要公开访问和业务模块混在一起。公开的静态资源如商品图和私密的合同附件应该分成两个桶因为前者可以配匿名只读策略后者必须走预签名链接。混在一个桶里策略很难写对。2.4 上传路径的设计直传还是中转这是架构上最需要提前决策的一点。所谓中转上传是浏览器把文件先传给 Java 服务服务再转手 PUT 到 MinIO直传则是服务端签发一个临时上传凭证预签名 URL浏览器直接和 MinIO 通信。两者取舍很清楚中转实现简单、服务端能做校验和转码但文件字节要过一遍应用服务器大文件会占带宽和内存直传省掉了这层中转但需要额外处理凭证有效期、上传后的回调确认。我的经验是小于 20MB 的常规附件走中转代码简单、可控性强超过 50MB 的音视频、大压缩包走直传否则一个 500MB 的视频能把服务的堆内存顶穿。中间的区间按实际业务量决定。这条决策会直接影响后面的代码形态所以一定要在动手前定下来别写完中转再回头改成直传改动面会很大。3. 核心细节拆解从初始化到对象操作的每一步3.1 客户端初始化与配置项的含义基础配置我一般放在application.yml里至少包含端点、凭证、默认桶、区域四项app: minio: endpoint: http://127.0.0.1:9000 access-key: your-access-key secret-key: your-secret-key bucket: app-prod region: us-east-1endpoint这里有个高频坑如果你的 MinIO 前面挂了反向代理endpoint 必须写成对外可访问的域名而不是127.0.0.1。因为预签名 URL 是用这个 endpoint 参与签名的如果签名时填的是内网地址返回给浏览器的链接就是内网地址用户根本打不开。我遇到过一次排查了半天的问题最后发现就是这一项配错了。region在自建 MinIO 里通常固定填us-east-1它不是真正的地理区域但 SDK 签名时会带上值不一致会报签名错误。凭证部分千万不要硬编码用环境变量或配置中心注入本地开发可以放在不提交的application-local.yml里。初始化 Bean 的写法和要点Configuration public class MinioConfig { Bean public MinioClient minioClient(MinioProperties props) { return MinioClient.builder() .endpoint(props.getEndpoint()) .credentials(props.getAccessKey(), props.getSecretKey()) .region(props.getRegion()) .build(); } }注意MinioClient是线程安全的交给 Spring 管理成单例即可。不要在方法内部重复构建也不要在使用后调用任何关闭方法它没有需要手动释放的生命周期。3.2 桶的创建与存在性检查首次部署时桶可能还不存在我习惯在应用启动时做一次幂等检查。这里的关键是理解bucketExists只回答有没有makeBucket在已存在时会抛异常所以要组合使用public void ensureBucket(String bucket) { try { boolean exists client.bucketExists( BucketExistsArgs.builder().bucket(bucket).build()); if (!exists) { client.makeBucket(MakeBucketArgs.builder().bucket(bucket).build()); } } catch (Exception e) { throw new IllegalStateException(桶初始化失败: bucket, e); } }这段看着简单但有几个细节值得说。第一异常不能吞桶建不出来后面所有操作都会失败启动时就该快速失败而不是等到用户点上传才报错。第二多实例同时启动时这段会并发执行makeBucket可能有一方抛已存在所以更稳妥的写法是捕获该异常并忽略或者直接用ifNotExists语义的封装。第三桶策略比如给公开桶配匿名只读建议也放在这一步统一设置避免人工在控制台点点点环境一换就忘了。3.3 对象命名别拿原始文件名当 key用原始文件名做 objectName 是最常见的偷懒做法后果是同名文件互相覆盖、中文和特殊字符导致 URL 编码问题、路径穿越风险文件名里带../。我的做法是用带日期的雪花 ID 或 UUID 作为对象名原始文件名只存数据库public String buildObjectName(String originalName, String bizType) { String ext ; int dot originalName.lastIndexOf(.); if (dot -1 dot originalName.length() - 1) { ext originalName.substring(dot).toLowerCase(); } String date LocalDate.now().format(DateTimeFormatter.ofPattern(yyyy/MM/dd)); return bizType / date / UUID.randomUUID() ext; }这样生成的对象名类似contract/2024/06/12/8f3c....pdf。前缀给业务类型中间给日期分层好处是对象在桶里按目录感组织运维排查和按前缀批量清理都方便日期的层级让冷数据归档、按周期删除变得可操作用listObjects加前缀就能筛扩展名保留浏览器下载时 MIME 推断更准。扩展名的提取逻辑要小心lastIndexOf(.)之后还要判断 dot 是否为最后一个字符否则file.这种会得到空串。另外可以加一个白名单校验不允许.exe、.jsp之流尤其是公开桶里的资源。3.4 上传流式与内存的取舍putObject是核心 API但参数选错会导致内存问题。看这段public String upload(InputStream in, long size, String contentType, String objectName) throws Exception { client.putObject( PutObjectArgs.builder() .bucket(bucket) .object(objectName) .stream(in, size, -1) .contentType(contentType) .build()); return objectName; }stream(stream, objectSize, partSize)三个参数很关键objectSize是必须给的SDK 需要它来决定分片策略和签名传-1表示未知大小这时会强制走分片上传且partSize必须显式指定最小 5MBpartSize传-1表示由 SDK 按大小自动决定分片但只在objectSize已知时才允许。所以如果是从MultipartFile拿到的流file.getSize()直接填进去就行partSize给-1。如果大小确实未知比如从网络流边下边传那就必须给固定分片大小比如10 * 1024 * 1024。这一条我踩过给未知大小传了partSize -1SDK 直接抛参数校验异常报错信息还不够直白查文档才明白。另一个重点是contentType一定要传。不传的话MinIO 存的是application/octet-stream浏览器点击图片链接会变成下载而不是预览用户体验很割裂。取值从MultipartFile.getContentType()拿即可但要注意这个方法返回的可能是null某些客户端不传需要兜底成application/octet-stream。3.5 下载与流的管理最容易漏的一环下载分两种场景服务端需要读取内容做处理比如解析 Excel、生成缩略图或者直接把文件透传给前端。前者用getObject拿到InputStream后者更推荐用预签名 URL 让浏览器自己取。先说服务端读取。GetObjectResponse本身是一个InputStream必须显式关闭否则底层连接不会归还连接池。正确写法try (InputStream in client.getObject( GetObjectArgs.builder().bucket(bucket).object(objectName).build())) { // 处理流 } catch (Exception e) { // 记录并抛业务异常 }我见过最典型的泄漏写法是在finally里只关了业务流的包装层而没关GetObjectResponse或者干脆什么也没关。表现是跑一段时间后上传下载开始变慢、偶发超时用连接监控一看全是 CLOSE_WAIT。记住任何从 SDK 拿到的流都要放进 try-with-resources。如果只是要透传给前端下载用GetObjectResponse配合StreamingResponseBody也可以但要注意大文件会长时间占用一个 Tomcat 工作线程并发上来后线程池会打满。所以除非必须做权限校验后的转发否则优先走预签名 URL。3.6 预签名 URL有效期与权限的平衡预签名presignedURL 的本质是用服务端凭证把一次操作的授权签进链接里拿到链接的人在这个有效期内可以凭链接做对应操作不需要再带凭证。生成方式String url client.getPresignedObjectUrl( GetPresignedObjectUrlArgs.builder() .method(Method.GET) .bucket(bucket) .object(objectName) .expiry(15, TimeUnit.MINUTES) .build());有效期怎么定原则是够用就好宁短勿长。下载链接给 15 分钟到 1 小时基本覆盖一次点击到下载完成的场景上传链接给 10 到 30 分钟因为用户可能选完文件还要填表单。MinIO 对预签名有效期有上限约束默认最长 7 天别想着签一年省事那等于把文件变成公开的。还有一个容易忽略的细节getPresignedObjectUrl生成的链接里包含 endpoint 的 host所以前面说的 endpoint 必须是外部可访问地址这里再强调一次。另外如果链接会出现在邮件、消息里被转发考虑加上时间戳和一次性标识在业务层做二次校验因为预签名 URL 本身无法主动失效。4. 实操落地把完整的上传下载链路跑起来4.1 表结构与元信息字段设计动手写代码前先把表定下来后面所有逻辑都围绕它转。我用的最小字段集如下字段类型说明idbigint主键object_namevarchar(255)存储对象名唯一original_namevarchar(255)原始文件名展示用bucketvarchar(63)所属桶便于多环境迁移sizebigint字节数content_typevarchar(127)MIME 类型biz_typevarchar(63)业务类型便于归类biz_idvarchar(63)关联业务主键statustinyint0 临时 1 正式 2 已删除created_byvarchar(63)上传人created_atdatetime上传时间object_name上加唯一索引(biz_type, biz_id)加联合索引用于业务查询created_at加索引支持按时间清理。status这个字段很有用上传成功但业务提交失败的文件可以标记成临时由定时任务在若干天后清理掉避免桶里堆垃圾。4.2 上传接口的完整实现下面这段是从 Controller 到 Service 的完整链路含参数校验和异常兜底PostMapping(/upload) public ResultFileVO upload(RequestParam(file) MultipartFile file, RequestParam(bizType) String bizType) { if (file.isEmpty()) { return Result.fail(文件为空); } if (file.getSize() 200L * 1024 * 1024) { return Result.fail(超过单文件大小上限); } String original StringUtils.cleanPath(file.getOriginalFilename()); if (original.contains(..)) { return Result.fail(非法文件名); } return Result.ok(fileService.upload(file, bizType)); }Service 层public FileVO upload(MultipartFile file, String bizType) { String objectName buildObjectName(file.getOriginalFilename(), bizType); String contentType Optional.ofNullable(file.getContentType()) .orElse(application/octet-stream); try (InputStream in file.getInputStream()) { client.putObject(PutObjectArgs.builder() .bucket(bucket) .object(objectName) .stream(in, file.getSize(), -1) .contentType(contentType) .build()); } catch (Exception e) { throw new BizException(文件上传失败, e); } // 落库 FileRecord record new FileRecord(); record.setObjectName(objectName); record.setOriginalName(file.getOriginalFilename()); record.setBucket(bucket); record.setSize(file.getSize()); record.setContentType(contentType); record.setBizType(bizType); record.setStatus(1); fileRecordMapper.insert(record); return toVO(record); }几个实操要点先传存储再落库。反过来的话如果上传失败数据库里就会留下指向不存在对象的脏记录。万一落库失败桶里会留一个孤儿对象这个可以用定时任务扫库中无记录且创建时间超过一天的对象来清理。StringUtils.cleanPath是 Spring 提供的能处理../之类的路径穿越配合手动判断更稳。大小上限建议在网关、Spring 的max-file-size、业务代码三层都配任何一层漏了都可能被绕过。file.getInputStream()也要关虽然MultipartFile的实现通常会在请求结束后清理临时文件但显式关闭是更好的习惯。4.3 下载与预览预签名优先下载接口我一般是这样的逻辑先查库确认记录存在且状态正常再判断是走重定向还是流式返回。GetMapping(/{id}/url) public ResultString downloadUrl(PathVariable Long id, RequestParam(defaultValue false) boolean inline) { FileRecord record fileRecordMapper.selectById(id); if (record null || record.getStatus() 2) { return Result.fail(文件不存在); } GetPresignedObjectUrlArgs.Builder builder GetPresignedObjectUrlArgs.builder() .method(Method.GET) .bucket(record.getBucket()) .object(record.getObjectName()) .expiry(30, TimeUnit.MINUTES); if (inline) { // 追加响应头参数让浏览器内联预览 MapString, String queryParams new HashMap(); queryParams.put(response-content-disposition, inline; filename\ record.getOriginalName() \); builder.extraQueryParams(queryParams); } try { return Result.ok(client.getPresignedObjectUrl(builder.build())); } catch (Exception e) { throw new BizException(生成下载链接失败, e); } }这里有个很实用的技巧extraQueryParams可以往预签名里塞response-content-disposition和response-content-type让 MinIO 在返回时覆盖响应头。这样一来即使对象存的时候是application/octet-stream也能让浏览器按图片或 PDF 内联打开中文文件名也能通过filename*UTF-8的方式正确编码。这个能力在预览场景里几乎必用。注意response-content-disposition里的文件名如果含中文直接拼会乱码。正确做法是用URLEncoder.encode(name, StandardCharsets.UTF_8)编码并采用filename*UTF-8编码后名字的格式。4.4 大文件分片上传的落地思路超过一两百兆的文件走单次putObject虽然 SDK 内部也会分片但整个请求会占住一个连接很久中途网络抖动就全废了。更稳的做法是前端分片服务端组装或者用 MinIO 的分段上传 API 手动控制。手动分段的核心是三步createMultipartUpload拿到 uploadId每个分片uploadPart记录返回的 etag全部完成后completeMultipartUpload传入分片编号和 etag 列表。关键参数是分片大小除最后一片外每片最小 5MB最大 5GB最多 10000 片。所以规划时要反推假如要支持 1TB 的文件分片至少得 100MB 一片才不超上限10000 × 100MB 约 976GB。绝大多数业务用 8MB 或 16MB 一片足够太小会导致请求数暴增、元数据膨胀太大会让失败重传代价变高。我一般取 16MB在 200MB 到 5GB 的区间里重传成本可以接受。分片上传的难点不在 API而在中断恢复要把 uploadId 和已完成分片列表存下来用户续传时先查已完成分片跳过。这块如果做表结构至少要有upload_id、object_name、part_number、etag、size。不做续传的话至少要保证失败后能调用abortMultipartUpload清理否则 MinIO 里会留下一堆不可见的碎片占着空间却查不到。4.5 删除、批量清理与容量控制删除分两种软删除只改数据库状态对象保留物理删除调用removeObject。我通常的业务删除都是软删保留可恢复性然后用定时任务定期做物理清理。public void physicalDelete(FileRecord record) { try { client.removeObject(RemoveObjectArgs.builder() .bucket(record.getBucket()) .object(record.getObjectName()) .build()); } catch (Exception e) { log.warn(对象删除失败稍后重试: {}, record.getObjectName(), e); } fileRecordMapper.deleteById(record.getId()); }批量清理时用removeObjects传一个可迭代的对象列表比循环单删效率高得多它内部走了批量接口。定时任务扫临时文件时按status 0 且 created_at now - 7 天查分批处理每批 500 条以内避免一次拉太多。容量控制这块MinIO 本身支持桶配额quota可以在管理端设置总量上限。另外建议在应用层做一个简单的用量统计定期把桶的总大小写到一个监控指标里超过阈值告警否则磁盘写满是很难第一时间发现的。5. 常见问题与排查实录5.1 高频报错速查表下面这张表是我这几年处理过的问题里出现频率最高的按现象、原因、处置三列整理遇到问题可以先对照查现象常见原因处置启动报S3 API Requests must be made to API portendpoint 用了控制台端口9001改成 API 端口9000预签名链接 403 SignatureDoesNotMatchendpoint 与实际访问地址不一致或 region 配错统一 endpoint 为对外域名region 固定us-east-1上传后无法删除桶策略限制了删除权限检查凭证对应的策略补s3:DeleteObject报Part number must be an integer between 1 and 10000分片数超上限增大 partSize反推保证不超 10000 片隔一段时间后连接超时增多GetObjectResponse未关闭连接泄漏所有流放进 try-with-resources中文文件名下载乱码响应头没做编码用filename*UTF-8格式编码图片点开变下载上传时没设 contentType上传时显式传 contentType多实例部署部分文件 404早期用了本地磁盘或 endpoint 指向单节点统一走 MinIOendpoint 指向可访问地址5.2 几个值得单独讲的排查过程第一个案例是偶发超时。某服务压测时QPS 一过 150 就开始出现零星超时日志里是SocketTimeoutException。第一反应是 MinIO 性能问题但集群 CPU 和网络都很闲。后来用连接监控看主机上的 TCP 状态发现大量 CLOSE_WAIT说明应用侧拿了连接没关。翻代码找到一处下载逻辑getObject拿到的流只在一个分支里关闭异常分支直接抛出去了。改成 try-with-resources 后超时彻底消失。这个案例的教训是网络问题先排除资源泄漏再怀疑对端。第二个案例是预签名链接时而能打开时而 403。服务部署了两个实例hosts 里给 endpoint 写了两个内网 IP 做负载结果签出来的链接有时指向 A、有时指向 B而用户只能访问其中一个。这类问题的根因是签名用的地址和用户访问的地址不一致。解决方式是把 endpoint 固定成一个对外统一入口而不是在内网做轮询。第三个案例是上传大文件到 99% 失败。排查发现是网关的请求体大小限制和超时时间都用的默认值200MB 的文件传到后半段直接被断开。这类问题需要对整条链路排查网关的限制、反向代理的client_max_body_size和读写超时、应用的 multipart 上限、MinIO 自身的超时。任何一环没放开大文件都过不去。我的经验是大文件方案上线前拿一个接近上限的文件做一次完整回归比事后救火省事得多。5.3 独家避坑心得几条写文档里通常不会提、但实测很管用的经验本地开发和线上用同一套 SDK 参数。有些人在本地把partSize调得很小图快线上忘了改结果分片数暴涨元数据膨胀、性能反而下降。参数应该走配置环境之间只改 endpoint 和凭证。给putObject加上超时配置。SDK 底层的 OkHttp 默认超时可能不符合你的期望通过自定义OkHttpClient设置 connect/read/write 超时再传给MinioClient.builder().httpClient(...)能让故障暴露得更快而不是傻等。对象名不要包含中文和空格。虽然 MinIO 支持但在一些中间件、日志系统、URL 拼接里会不断给你制造麻烦用 ID 加扩展名是最省心的。测试环境定期清桶。测试环境最容易堆积垃圾文件磁盘告警往往第一个出现在测试环境。写个脚本按前缀删或者干脆定期重建桶。不要把凭证打日志。排查问题时打印配置很容易顺手把 secretKey 也打出来这个习惯一定要改日志脱敏要做在配置加载那一层。6. 收尾前再聊两句实践感受这套 Java 加 MinIO 的组合我从早期的单体项目一路用到现在的多服务架构最大的感受是它本身不难难的是边界和细节。API 就那么几个一天就能跑通 demo但真正让它稳定跑上一年半载的是那些不起眼的决定——对象名怎么生成、流有没有关、endpoint 配的是哪个地址、分片大小怎么定、临时文件谁来清。这些点每一个单独看都是小事凑在一起就是线上事故和正常运行的差别。我个人的习惯是每次接入一个新的存储实现先写一个小的验证程序把上传、下载、预签名、删除、分片这五条路径各跑一遍再拿一个 300MB 左右的文件压一次确认没有连接泄漏和超时然后才开始往业务代码里接。这个过程大概半天但能挡掉后面大部分的返工。另外提一句扩展方向如果将来文件量级继续涨可以在 MinIO 前面加一层 CDN 或者反向代理做缓存公开资源走缓存、私密资源仍走预签名如果要做内容安全扫描可以在上传成功后发一个异步事件由独立服务拉取对象做检测检测完再改状态。这些都是在现有结构上做加法不需要动核心链路这也是当初把存储层做哑的好处。

Java集成MinIO对象存储：上传下载、预签名与分片实践

相关推荐

GPT-6系列模型选型指南：API接入、Codex与AI Agent实战

BLIP-2多模态预训练：冻结策略与Q-Former信息压缩

功能测试中的等价类划分与边界值分析实战

更多资讯

TI AM64x PDMA架构本质：PSI-L与X-Y FIFO协同的数据流编排引擎

agent-skills 是什么？不是 npm 包，而是能力交付协议

多微电网电能交互与碳排放优化的ADMM实现

E2V相机串口指令调参：曝光、触发与增益链路避坑

Context-Mode：一种让复杂系统上下文不再混乱的设计模式

从数据源到可视化：省级行政区面积排行榜的工程化做法

今日更新

微信个人号API开发案例：图片/语音/视频消息怎么下载解析存到本地？

Python股票自动交易系统源码解析：从行情获取到风控的完整链路

视酷酷信IM源码部署指南：Java 17+MySQL 8.0.33实战配置

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？