ASP.NET文件夹上传安全设计：加密与防路径穿越实践

在金融保险行业做了几年系统，文件上传算是理赔、投保、归档这些链路里最不起眼、但最容易出问题的一环。业务方跟我说要支持文件夹上传的时候，我心里就很清楚，这绝不是前端加一个目录属性那么简单。文件夹上传意味着一次性可能进来几百个文件、深层目录结构、命名不规则的附件，以及各种格式的保单、身份证、医疗单据。保险行业对数据安全的要求又高：传输要加密、存储要加密、权限要隔离、操作要追溯。asp.net作为老牌的服务端技术栈，在这个场景下能做的和必须做的安全措施，远比多数人预想的多。这篇东西就是把我做过的金融保险类文件上传项目里，关于文件夹上传、加密和安全性这部分的设计思路、实现方法和踩坑记录完整梳理一遍，希望能帮到正在做类似系统的朋友。

1. 金融保险场景下文件夹上传的真实痛点

1.1 业务场景：不只是一个文件夹

先说说业务方为什么会提出“文件夹上传”这种需求。保险行业大量业务是线下材料电子化：车险理赔要上传事故照片、定损单、驾驶证、行驶证；寿险投保要上传身份证、银行卡、体检报告、健康告知书；保全业务要传申请书、关系证明。这些材料往往是按“案件”或“保单号”归集的，一个客户一次提交就是一堆文件。

最初的产品方案让用户逐文件选择，业务人员抱怨强烈：一次理赔事故现场照片可能几十张，一个个点选不仅慢，还容易漏，最难受的是完全看不出哪些文件属于哪个目录。后来改成文件夹上传，用户直接把本地的“事故照片文件夹”整体拖上去，前端自动递归展开，一秒钟拉出全部文件清单，服务端按相对路径重建目录，这才算是真正贴合业务。

1.2 为什么普通文件上传方案在保险行业撑不住

很多通用上传组件演示环境跑得很欢，拿到保险内网环境就崩，这不是组件本身问题，而是场景复杂度完全不同。

首先，金融保险行业的数据分类分级制度很严格，客户身份证号、银行卡号、病历信息这些属于敏感个人信息，文件落地必须加密。市面上大部分上传组件只做HTTP传输和MIME过滤，没有“存储层加密”概念。

其次，保险机构有明确的合规要求，包括系统操作留痕、日志保存期限、密码算法合规性等，这不是技术demo里能覆盖的。

第三，文件内容复杂。身份证照片可能是jpg/png，理赔单可能是pdf，业务证明材料可能是word或zip。不同格式文件的内容安全风险差异大，不能只靠扩展名判断，必须做内容级校验。

所以在这个领域做文件夹上传，本质上是在做一个“面向合规的、支持批量文件结构管理的安全文件传输子系统”，而不是简单堆一个input标签。

1.3 安全基线：从威胁模型反推设计

我习惯先想清楚要防什么，再动手写代码。金融保险场景上传链路的威胁模型大概包含以下几类：

后面所有设计，都是围绕这张表逐项去堵。每做一步都要问：我这一步到底防的是哪个威胁？如果回答不上来，那这个设计大概率是多余的。

2. 前端文件夹上传的实现方式与表单封装

2.1 基于webkitdirectory原生能力实现整目录选择

浏览器原生支持文件夹选择，关键属性就是webkitdirectory。在HTML里写起来很简单：

html复制<input type="file" id="folderInput" webkitdirectory directory multiple />

加上webkitdirectory后，弹出的是目录选择对话框，用户选定一个文件夹，input.files里会自动列出该目录下所有文件和子目录下的文件，而且每个文件对象上可以通过file.webkitRelativePath拿到相对路径，比如事故照片/车辆左前方.jpg。

需要注意的是：这个属性最早是Chrome实现的，所以带有webkit前缀。现代版本的Firefox、Edge都已经兼容了该属性，但为了稳妥，我一般会做特性检测，不支持的浏览器就降级为多文件选择：

javascript复制const input = document.getElementById('folderInput');
if ('webkitdirectory' in input) {
    input.setAttribute('webkitdirectory', '');
    input.setAttribute('directory', '');
} else {
    input.removeAttribute('webkitdirectory');
    input.removeAttribute('directory');
}

选完文件夹后的处理逻辑，我一般会先遍历统计，再逐个上传：

javascript复制input.addEventListener('change', (e) => {
    const files = Array.from(e.target.files || []);
    const fileList = files.map(file => ({
        file: file,
        relativePath: file.webkitRelativePath || file.name,
        size: file.size,
        lastModified: file.lastModified
    }));
    // 统计总大小，超过限制直接提示，避免无谓请求
    const totalSize = fileList.reduce((sum, item) => sum + item.size, 0);
    if (totalSize > MAX_TOTAL_SIZE) {
        alert('所选文件总大小超过限制');
        return;
    }
    // 展示文件树，让用户确认后点击上传
    renderFileTree(fileList);
});

2.2 服务端如何接收“文件夹”

很多人会困惑：服务端拿到的到底是一个文件夹对象还是一堆文件？答案是：文件夹的概念只存在于前端，服务端拿到的就是多个文件，每个文件带一个相对路径字段。

asp.net core的模型绑定处理多文件上传非常方便，接口签名可以直接写成：

csharp复制[HttpPost("upload/folder")]
[RequestSizeLimit(2_000_000_000)]
public async Task<IActionResult> UploadFolder([FromForm] List<IFormFile> files, [FromForm] string relativePaths)
{
    // relativePaths 是与 files 一一对应的相对路径列表，用分号/JSON序列化传递
}

我建议的前端提交方式是把relativePath作为额外的表单字段传过去。如果文件数量比较多，相对路径列表可以先在JS端序列化成JSON字符串，再append到FormData里：

javascript复制const formData = new FormData();
fileList.forEach((item, index) => {
    formData.append('files', item.file);
    formData.append('relativePaths', item.relativePath);
});
fetch('/api/upload/folder', {
    method: 'POST',
    body: formData
});

2.3 前端也要做的基础安全动作

很多前端工程师会把安全全部抛给后端，这不对。前端做基础校验能挡掉大量无谓请求，但前端校验不能替代后端校验。

前端要做的安全动作包括：

• 上传前按扩展名和文件签名做第一道过滤，可执行文件（exe、bat、dll、ps1等）直接拦截，减少恶意文件到达服务端的概率。
• 限制单文件大小和总大小，请求发出前先测算，超限就不发。
• 展示文件清单和目录树让用户确认，避免误传隐私文件。
• 上传过程中记录每个文件的进度，失败的自动重试，但重试次数最多三次，避免对服务器造成压力。

这里要特别提醒一下：前端限制是友好的拦截，不是安全边界。攻击者完全可以绕过前端直接构造请求，所以服务端必须把同样的校验重复做一遍甚至做更严。我在项目里见过一个案例，前端限制了只允许传图片，后端没做校验，结果有人直接绕过前端传了webshell，如果不是内网环境隔离得严，后果不堪设想。

3. 传输链路加密：不只挂个HTTPS证书那么简单

3.1 IIS和Kestrel的TLS规范配置

金融保险行业传输层加密一般会明确要求TLS1.2及以上，禁用SSL2/SSL3/TLS1.0。这个要求不只是配置证书那么简单。IIS上可以通过注册表或组策略关掉旧协议，在IIS站点的“SSL设置”里强制要求SSL，同时把“客户端证书”设为“忽略”。

对于asp.net core应用部署在IIS上，需要在web.config的system.webServer里配置安全请求头：

xml复制<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
      <add name="X-Content-Type-Options" value="nosniff" />
      <add name="X-Frame-Options" value="DENY" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

HSTS（Strict-Transport-Security）头的作用是告诉浏览器：这个域名只能走HTTPS，后续访问直接跳过明文的HTTP跳转过程。这个头在保险内网系统里一定要配，而且max-age建议一年起步。

3.2 证书是外购还是内网CA

金融公司内部系统通常有两种证书方案：对外服务的用权威CA签发的证书，内网系统用企业内部CA签发的证书。无论哪种，都要注意证书链完整和私钥保管。

我在做保险项目时遇到一个很典型的坑：运维把内网CA根证书只下发到部分业务电脑，导致另一部分电脑访问上传系统时出现“证书不受信任”的警告，业务人员不敢继续操作，最后是IT部门统一域推送根证书才解决。所以在上线前，一定要在目标用户群体覆盖的终端上做证书信任验证，最好是形成“根证书安装操作手册”一起发布。

3.3 传输层完整性校验：文件哈希

HTTPS本身保证传输过程不被篡改，但服务端接收到的文件是否和客户端发送的一致，还需要应用层校验。对于文件夹上传这种大文件批量场景，我一般会在前端计算每个文件或每个分块的SHA256哈希，随表单一起提交，服务端接收后重新计算哈希并比对。

csharp复制using var sha256 = SHA256.Create();
await using var stream = file.OpenReadStream();
byte[] hashBytes = await sha256.ComputeHashAsync(stream);
string hash = Convert.ToHexString(hashBytes);

哈希比对的意义有两个：一是检测传输过程的偶发损坏（比如网络丢包导致文件字节变化），二是后续审计日志里可以记录文件的“数字指纹”，一旦发生安全事件可以快速定位文件自始至终是否被篡改过。这个字段我在设计数据库时一定加进去，而且建议设置索引。

4. 服务端接收与存储加密：从临时目录到加密落盘

4.1 接收管道设计：临时目录、大小限制、超时控制

服务端接收文件夹上传，不能直接把文件写进业务存储目录，必须经过一个“临时隔离区”。这是我反复强调的安全设计，因为文件在没有完成安全检测之前，绝不能进入业务目录。

推荐的接收流程图：

1. 请求到达上传接口，先做身份认证和权限校验。
2. 校验文件数量、单文件大小、总大小。asp.net core里光配一个特性不够，多个限制要组合使用：

csharp复制builder.Services.Configure<FormOptions>(options =>
{
    options.MultipartBodyLengthLimit = 2_000_000_000; // 2GB
});

如果是部署在IIS上，还需要同步修改web.config中的maxAllowedContentLength，否则IIS会在asp.net core之前直接拒绝请求：

xml复制<system.webServer>
  <security>
    <requestFiltering>
      <requestLimits maxAllowedContentLength="2147483648" />
    </requestFiltering>
  </security>
</system.webServer>

3. 文件先写入临时目录，目录名建议用GUID命名，避免可推测的路径。
4. 单文件落盘后立刻计算哈希，与前端的哈希比对。
5. 全部文件落盘后，进入安全检测流程（见第5节）。
6. 检测通过后，按业务规则重新组织目录结构，移入加密存储区。

4.2 路径穿越攻击与服务端文件名重组

这是文件夹上传最容易出安全问题的地方，必须单独拎出来讲。

文件夹上传天然带有“路径”信息，如果代码直接拼接客户端传过来的relativePath，攻击者传一个../../../../windows/system32/shell.exe，就可能覆盖服务器上的任意文件。即使app账号权限有限，也可能造成拒绝服务或注入恶意文件。

服务端正确的做法是：绝对不信任任何客户端传来的路径字符串。接收后只做一件事：取文件名，丢弃路径结构。

csharp复制string safeFileName = Path.GetFileName(relativePath);

Path.GetFileName会自动截取最后一个分隔符后的部分，..、反斜杠、正斜杠都会被处理掉。但GetFileName还有一些边界情况要小心，比如文件名包含特殊字符、Unicode控制字符等，所以更稳妥的方案是自己实现一个白名单字符过滤：

csharp复制private static readonly HashSet<char> AllowedFileNameChars = new HashSet<char>(
    "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789._-（）()【】[] "
);

public static string SanitizeFileName(string fileName)
{
    if (string.IsNullOrWhiteSpace(fileName)) throw new ArgumentException("文件名不能为空");
    char[] invalidChars = Path.GetInvalidFileNameChars();
    var safeChars = fileName.Where(c => !invalidChars.Contains(c) && AllowedFileNameChars.Contains(c)).ToArray();
    string safe = new string(safeChars);
    if (string.IsNullOrWhiteSpace(safe)) throw new ArgumentException("文件名不合法");
    return safe.Trim().TrimEnd('.');
}

服务端重组目录的维度不要用客户端传的路径，而是用自己的业务标识，比如“案件编号/上传批次号/文件序号_安全文件名”。这样既保留了文件夹的语义，又彻底隔断了路径注入的可能。

在传统asp.net（Framework 4.x）里，还需要注意requestValidation。早年的WebForms项目经常会遇到“检测到有潜在危险的Request.QueryString值”的报错，本质是ASP.NET默认对输入做了严格校验，如果文件名里带了<、>之类的字符就会被拦。遇到这种问题，安全正确的处理方式是保持默认校验开启，同时调整前端的提交方式，确保所有数据都以multipart/form-data的方式传输，不要把文件名塞进QueryString里去绕过校验。如果确实需要接收特殊字符，要对输入做严格的HTML编码和SQL参数化处理，不能图省事关掉整个页面的验证。

4.3 存储层加密方案：AES-256-GCM还是SM4-CBC

文件落盘加密是这个项目的核心。加密算法选择上，金融保险行业往往还有国密合规的要求，所以一般是两套方案：普通商业项目用AES-256-GCM，有国密要求的用SM4-CBC。

先看AES-256-GCM，这是.NET原生支持的，API非常简单：

csharp复制public static byte[] AesGcmEncrypt(byte[] plainBytes, byte[] key, byte[] nonce, out byte[] tag)
{
    using var aes = new AesGcm(key, 16); // 128位tag
    byte[] cipherBytes = new byte[plainBytes.Length];
    byte[] tagBytes = new byte[16];
    aes.Encrypt(nonce, plainBytes, cipherBytes, tagBytes);
    tag = tagBytes;
    return cipherBytes;
}

GCM是AEAD模式，加密的同时能提供完整性校验，解密时如果文件被篡改，会直接抛出AuthenticationTagMismatchException，这对金融行业的文件完整性要求来说非常合适，强烈推荐。

再看SM4-CBC，如果客户有国密算法合规的要求，就要用SM4。.NET本身没有内置SM4实现，一般引用BouncyCastle这个加密库。我贴一段实际项目中封装的SM4加解密逻辑关键代码：

csharp复制using Org.BouncyCastle.Crypto.Engines;
using Org.BouncyCastle.Crypto.Modes;
using Org.BouncyCastle.Crypto.Paddings;
using Org.BouncyCastle.Crypto.Parameters;

public static class Sm4Helper
{
    public static byte[] Encrypt(byte[] plainBytes, byte[] key, byte[] iv)
    {
        var engine = new SM4Engine();
        var cipher = new PaddedBufferedBlockCipher(new CbcBlockCipher(engine));
        var keyParam = new KeyParameter(key);
        var parameters = new ParametersWithIV(keyParam, iv);
        cipher.Init(true, parameters);
        byte[] output = new byte[cipher.GetOutputSize(plainBytes.Length)];
        int length = cipher.ProcessBytes(plainBytes, 0, plainBytes.Length, output, 0);
        length += cipher.DoFinal(output, length);
        return output.Take(length).ToArray();
    }
}

这里必须强调一点：BouncyCastle的SM4Engine类的命名空间在不同版本里可能不同，老版本是Org.BouncyCastle.Crypto.Engines.SM4Engine，新版在Org.BouncyCastle.Crypto.Engines下。引包之前先确认一下版本，避免编译报错。

4.4 加密后的密钥管理：不能写死在web.config

加密算法选得再好，密钥泄露等于白搭。我见过很多项目把AES密钥直接放在web.config的appSettings里，明文躺在服务器上，数据库被拖走后加密文件也能被解开，这是最致命的安全漏洞。

正确的密钥管理路径有三个层次：

即使没有外部KMS，至少要做到：配置文件里存放的不是明文密钥，而是经过DPAPI加密的密文密钥，应用启动时调用ProtectedData.Unprotect解析。更进一步的做法是用证书加密密钥，私钥保存在服务器证书存储区。

我在保险项目中的标准做法是：每个业务目录使用独立的“数据加密密钥（DEK）”，DEK由“主密钥（KEK）”加密后存储在数据库或配置中心。这样即便某个DEK泄露，也只影响一个目录以下的历史数据，可以通过轮换DEK快速止血，不需要重新加密所有文件。

同时，密钥一定要做轮换机制。金融行业通常要求半年到一年轮换一次。轮换的策略是“先解密旧数据，再用新密钥重新加密”，这在文件量巨大的场景下是个不小的工程。更务实的方案是采用信封加密：文件用随机生成的DEK加密，DEK用KEK加密存储，轮换时只需重新加密DEK，不需要动文件。这个方案强烈推荐给量大、文件不可变的场景。

5. 文件内容安全检测与越权防护

5.1 文件类型白名单：不看扩展名看魔法字节

只看扩展名判断文件类型，在金融行业绝对不过关。扩展名可以随便改，更可靠的是读取文件头部的“魔法字节”。比如：

实现一个简单的魔法字节检测：

csharp复制public static string DetectFileType(byte[] header)
{
    if (header.Length < 4) return "unknown";
    if (header[0] == 0xFF && header[1] == 0xD8 && header[2] == 0xFF) return "jpg";
    if (header[0] == 0x89 && header[1] == 0x50 && header[2] == 0x4E && header[3] == 0x47) return "png";
    if (header[0] == 0x25 && header[1] == 0x50 && header[2] == 0x44 && header[3] == 0x46) return "pdf";
    if (header[0] == 0x50 && header[1] == 0x4B) return "zip";
    return "unknown";
}

检测通过后，服务端保存文件时完全可以用服务端检测出的类型作为判断依据，不为扩展名而烦恼。然后做一层映射：只有白名单内的类型才允许进入业务目录，其余一律隔离并记为异常文件。

5.2 病毒扫描与内容安全联动

文件上传到服务器后，立刻进行病毒扫描在金融行业是刚需。asp.net应用本身没有病毒扫描能力，一般通过两种方式联动：

一是集成第三方防病毒引擎的API或ICAP协议，比如内网部署的瑞星、奇安信、ClamAV等。

二是利用Windows的AMSI（反恶意软件扫描接口）或Windows Defender。这种方式在Windows Server上比较方便，可以调用mpcmdrun.exe或者WMI接口触发扫描。

我常用的是异步扫描方案：上传接口先把文件放在隔离目录，立即返回“接收成功，正在安全检测”，同时启动后台任务扫描，检测通过后再把文件移入正式存储目录。前端通过轮询“处理状态”接口来更新上传结果。这样做的原因很现实：大文件杀毒可能要几秒到几十秒，如果同步扫描，上传接口的超时时间会很难控制，前端也容易误报失败。

5.3 基于会话和角色的上传授权模型

权限控制这一层，关键不是写一个判断，而是建立起完整的模型。文件夹上传并不是谁都能调的接口。我设计时遵循几个原则：

• 上传接口必须经过身份认证，asp.net core里用[Authorize]，传统Framework用[Authorize]或Session校验。
• 接口必须防CSRF。asp.net core中，在MVC控制器加[ValidateAntiForgeryToken]，前端从服务端获取防伪令牌后放在请求头或表单里提交。
• 业务目录的权限要和“案件归属”绑定，一个理赔员只能上传到自己经办或本团队的案件目录。

asp.net core里可以写一个自定义AuthorizationHandler，在请求上下文中取出“当前用户可访问的案件ID列表”，再和上传请求中的“目标业务目录”做比对：

csharp复制public class FolderUploadAuthorizationHandler : AuthorizationHandler<FolderUploadRequirement>
{
    protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context,
        FolderUploadRequirement requirement)
    {
        // 从context.User中取用户ID、部门、角色
        // 从httpContext.Request.Form中取businessCaseId
        // 校验该用户是否有权向指定caseId上传文件
        // 有权限则context.Succeed(requirement)
    }
}

6. 金融合规增强：审计日志、国密改造与数据隔离

6.1 审计日志必须记录的字段

金融行业的系统审计要求非常具体，审计日志不能随手打两行就算完。我根据监管验收的实际经验，整理了一个支持文件夹上传系统至少要记录的最小字段集：

日志要集中存储，不能只写服务器本地文件，因为服务器被入侵后日志可能一起被篡改。可以把日志写到独立的日志库、Elasticsearch或安全审计平台。传输日志到日志平台时建议加HMAC签名，防止日志被篡改后无法发现。

6.2 国密SM4改造的落地过程

有国密要求的保险项目，替换加密算法要做的不是简单换一个类，而是一整套兼容方案。

首先是算法库选型。.NET生态里目前最常用的是BouncyCastle（有国密支持），商业用户也可以购买国内密码厂商提供的中间件。需要注意，SM4的加解密结果要配合“密钥、IV、填充模式、CBC/ECB模式”才能确定，两个系统之间互操作时，这些参数必须完全一致，否则密文解不开。

其次是存量数据迁移。老系统如果是用AES加密的文件，迁移到SM4之前要先设计双算法支持期。我的做法是：文件加密后，在存储格式里保留一个“算法标识”字段：

code复制[加密文件头] | [算法标识 1字节] | [IV] | [密文数据]

这样应用读取文件时，先解析算法标识，再决定用哪个算法解密。这样新旧文件可以共存，数据迁移过程中不需要一次性重加密，可以分批平滑推进。

6.3 数据隔离：租户/渠道/保单维度的文件夹抽象

文件夹上传背后，存储层不应该直接暴露物理路径给应用层，建议抽象一层“虚拟目录”。在保险场景里，这个虚拟目录可以是：

code复制/保单号/上传批次号/文件序号_文件名

从数据库视角来看，可以设计一张“文件目录表”：

这张表既实现了业务维度的隔离，又是权限控制的依据。查询时只能通过“当前的用户->有权限的案件列表->文件目录表”三层过滤后才能拿到数据，从架构上杜绝了遍历接口的可能。

7. 上线前必须做的验证与我在实际项目中的踩坑记录

7.1 安全自测清单

在交付金融客户之前，我通常会拿一份自测清单过一遍，这份清单是从真实项目里沉淀出来的：

7.2 三个典型踩坑案例

第一个坑：IIS的maxAllowedContentLength没同步设置。asp.net core项目在Kestrel层配好了MultipartBodyLengthLimit，部署到IIS之后发现超过30MB的文件直接返回413，我当时找了半天，最后发现是IIS的requestFiltering默认限制。这个坑在asp.net core部署到IIS时几乎必踩，各位一定注意。

第二个坑：文件夹上传时文件名编码。中文文件名、日文文件名在上传过程中如果前端没有显式指定UTF-8编码，服务端解析出来就会乱码。最终落盘的文件名从乱码变成了????.pdf，这在保险业务里是不可接受的，因为后续审计追踪对不上。解决方法是前端FormData提交时使用UTF-8，服务端在处理multipart/form-data时也明确指定UTF-8，两边都统一，不要在某个环节做额外的编码转换。

第三个坑：临时目录没有定期清理。某次上线后运维反馈服务器磁盘被占满，排查发现是上传接口在请求异常时没有走finally清理临时文件，大量失败请求留下的半截文件堆在临时目录里。后来我统一封装了一个UploadTempFileCleaner服务，定时清理超过24小时且未进入正式存储区的临时文件，磁盘占用一下就稳定了。

7.3 后续可以扩展的几个方向

如果你们的业务量持续增长，这个文件夹上传系统还可以往下延伸：

一是引入分块上传和断点续传。文件夹里如果包含几十GB的影像文件，单次HTTP请求很容易超时，分块后每块哈希独立校验，断点处继续上传，用户体验和系统稳定性都有质的提升。

二是做上传进度和服务端状态的实时推送。asp.net core里可以用SignalR把“杀毒进度”“文件解析进度”推送给前端，替代轮询机制，体验更顺滑。

三是结合对象存储OSS/MinIO把文件加密从本机搬到存储服务层。很多对象存储支持服务端SSE-KMS加密，密钥由存储服务统一管理，应用层只需要处理访问凭证和路径控制即可，复杂度反而降低了。

四是做敏感数据自动识别。上传的文件可以先经过OCR或内容识别服务，自动判断是否包含身份证号、银行卡号等敏感信息，根据识别结果自动调整文件的访问权限和加密等级，这是保险行业数据安全治理比较前沿的方向。

我在做文件夹上传加密这个需求时最大的体会是：安全不是一个点，而是一条完整的链路。前端选择目录、传输加密、服务端接收隔离、文件内容检测、存储加密、密钥管理、审计追溯，每个环节少一个，整条链路就可能出缺口。金融保险行业的数据尤其敏感，出一次事故就不是技术问题而是合规风险。所以宁可前期多做一些设计，宁可功能上做得慢一点，安全这件事也不能图省事。