C#字符串加解密实战：AES、RSA与SHA-256工具类详解-北京尧图网络

1. 项目概述与加解密方案选型1.1 这个项目到底在解决什么问题字符串加解密这玩意儿几乎每个做 .NET 开发的人都会碰到。无论是接口参数签名、数据库敏感字段脱敏还是配置文件里的连接串保护本质上都绕不开把一串明文变成别人看不懂的密文需要的时候再变回来这个最基本的需求。我最早接触 C# 字符串加解密是在做一个后台管理系统的时候需要对用户的手机号、身份证号做入库前的加密存储。当时网上搜到的资料五花八门有的直接拿 Base64 冒充加密有的把 DES 密钥写死在代码里还有的用 MD5 加完密之后一脸茫然地问为什么解不出来——因为哈希根本不是可逆加密。这个项目的核心目标很明确用 C# 提供一套开箱即用的字符串加解密工具代码覆盖最常见的哈希摘要、对称加密、非对称加密三大类场景并且把每个方案的适用条件、参数要求、坑点陷阱都讲清楚。源码可以直接复制到项目里用也能帮你理解背后那些容易忽略的细节。适合谁来参考如果你刚接触 C# 加密相关 API或者已经在用但是经常踩解密失败中文乱码密钥长度不对这类坑这篇内容能直接帮你省下不少排查时间。我尽量用实际场景的口吻来写把我在项目里真正碰到过的问题拿出来说。1.2 加解密方案对比哈希、对称、非对称怎么选很多初学者上来就问哪种加密最好这是个伪命题。不同场景对应不同方案先搞清楚你要的是不可逆摘要还是可逆加密再往下选型。哈希算法的特点是单向不可逆MD5、SHA-1、SHA-256 都属于这一类。它适合做数据完整性校验、密码指纹存储、接口签名。MD5 虽然计算快但碰撞风险高、彩虹表攻击成本低现在已经不推荐用于安全敏感场景不过做一些内部数据指纹、缓存键生成还是没问题的。SHA-256 是当前更稳妥的默认选择即使不考虑安全问题它的输出长度更长碰撞概率也低得多。对称加密的特点是加密和解密用同一个密钥常见的有 DES、3DES、AES。DES 的密钥只有 56 位有效位早已被证明不够安全我在新项目里一律不碰。AES 是当前主流密钥长度支持 128、192、256 位配合 CBC 模式和 PKCS7 填充是绝大多数业务场景下够用且稳妥的组合。对称加密性能好适合加密大批量数据比如用户手机号、身份证号、订单号这类字段。非对称加密的特点是有一对密钥公钥加密、私钥解密常见的是 RSA。它解决的是密钥分发问题——你把公钥给谁都不怕只有持有私钥的人才能解开。但 RSA 性能比 AES 慢几个数量级而且加密长度有限制所以不适合直接加密长文本。实际场景里经常用混合方案用 RSA 加密一个随机生成的 AES 密钥再用这个 AES 密钥加密真正的业务数据。选型时我习惯先画三条线需要还原明文就选 AES 或 RSA不需要还原、只做校验就选 SHA-256 或 HMAC密钥要分发给多方就选 RSA。至于 Base64它不是加密是编码后面我会专门说。1.3 为什么选 C# 来做这件事C# 做字符串加解密有一个天然优势.NET 内置的System.Security.Cryptography命名空间把主流算法都封好了MD5、SHA 系列、AES、RSA、HMAC、PBKDF2 全都开箱即用不需要引入第三方包。这意味着代码的可移植性和可维护性都很强目标框架升级了 API 也基本兼容团队其他人接手时也不容易懵。另一个好处是 C# 的流式处理模型。加密这块大量涉及字节流的转换.NET 的CryptoStream可以把加密逻辑无缝嵌入到文件流、内存流、网络流里不光是字符串做文件加密、流加密也是一套思路。我后面给出的工具类就是以字符串为入口但核心写法稍微改一下就能扩展到任意数据源。2. 核心原理与代码实现2.1 哈希算法MD5 和 SHA-256 的实现细节哈希算法的本质是把任意长度的输入通过散列函数映射成固定长度的输出。C# 里调用方式非常统一都是XXX.Create()拿到算法实例然后调用ComputeHash处理字节数组。先看 MD5 的实现代码using System.Security.Cryptography; using System.Text; public static string Md5Hash(string input) { if (string.IsNullOrEmpty(input)) return string.Empty; using (MD5 md5 MD5.Create()) { byte[] inputBytes Encoding.UTF8.GetBytes(input); byte[] hashBytes md5.ComputeHash(inputBytes); return Convert.ToHexString(hashBytes).ToLower(); } }注意三点。第一编码一定要统一。我在项目里见过有人用Encoding.Default结果系统区域设置一变同样的字符串算出来的哈希全都不一样排查起来非常痛苦。统一用Encoding.UTF8跨系统结果才一致。第二输出格式要预先想好。Convert.ToHexString是 .NET 5 之后提供的方法直接输出大写十六进制字符串。如果你在 .NET Framework 环境跑需要自己手写一个字节转十六进制的逻辑常见写法是byte.ToString(x2)循环拼接。我习惯把是否大写作为参数暴露出来因为不同对接方要求的格式可能不一样。第三MD5 的安全性。MD5 已经被实践证明不抗碰撞做密码存储绝对不要直接用它。如果只是做数据指纹、缓存 Key、文件校验MD5 的高性能还是可以接受的。我在代码注释里会写明仅供非安全场景使用避免同事不明就里拿去存密码。SHA-256 的代码几乎一模一样public static string Sha256Hash(string input) { if (string.IsNullOrEmpty(input)) return string.Empty; using (SHA256 sha256 SHA256.Create()) { byte[] inputBytes Encoding.UTF8.GetBytes(input); byte[] hashBytes sha256.ComputeHash(inputBytes); return Convert.ToHexString(hashBytes).ToLower(); } }说句题外话SHA-256 输出 64 个十六进制字符MD5 只有 32 个。同样的输入长度下SHA-256 碰撞概率更低而且目前没有实际可行的碰撞攻击所以新项目里凡是存密码、做签名我全部默认 SHA-256。不过存密码我其实更推荐 PBKDF2哈希一次远远不够。用户密码这种低熵数据直接算 SHA-256 一样可以被彩虹表快速命中。正确的姿势是加盐多次迭代。C# 里的实现是这样public static byte[] DerivePasswordKey(string password, byte[] salt, int iterations 10000) { using (Rfc2898DeriveBytes pbkdf2 new Rfc2898DeriveBytes( password, salt, iterations, HashAlgorithmName.SHA256)) { return pbkdf2.GetBytes(32); // 32字节 256位 } }盐salt必须随机生成并且每个用户都不一样。校验的时候从数据库取出盐用相同的迭代次数重新派生再比对结果。PBKDF2 会把 10000 次迭代的耗时放大到几毫秒级别这个成本对用户来说可以忽略但对暴力破解来说是实实在在的阻力。2.2 对称加密AES 完整实现及参数详解AES 是业务系统里用得最多的可逆加密方案。我一开始用对称加密的时候踩过一个大坑照着网上的代码抄却发现解密一直抛 Padding is invalid and cannot be removed。后来才搞明白是密钥长度和 IV 长度没配对。先把完整实现放出来再逐项解释为什么参数必须是这样的。using System.Security.Cryptography; public static string AesEncrypt(string plainText, string key, string iv) { if (string.IsNullOrEmpty(plainText)) return string.Empty; using (Aes aes Aes.Create()) { aes.Mode CipherMode.CBC; aes.Padding PaddingMode.PKCS7; aes.Key Encoding.UTF8.GetBytes(key); aes.IV Encoding.UTF8.GetBytes(iv); ICryptoTransform encryptor aes.CreateEncryptor(); byte[] plainBytes Encoding.UTF8.GetBytes(plainText); byte[] cipherBytes encryptor.TransformFinalBlock(plainBytes, 0, plainBytes.Length); return Convert.ToBase64String(cipherBytes); } } public static string AesDecrypt(string cipherText, string key, string iv) { if (string.IsNullOrEmpty(cipherText)) return string.Empty; using (Aes aes Aes.Create()) { aes.Mode CipherMode.CBC; aes.Padding PaddingMode.PKCS7; aes.Key Encoding.UTF8.GetBytes(key); aes.IV Encoding.UTF8.GetBytes(iv); ICryptoTransform decryptor aes.CreateDecryptor(); byte[] cipherBytes Convert.FromBase64String(cipherText); byte[] plainBytes decryptor.TransformFinalBlock(cipherBytes, 0, cipherBytes.Length); return Encoding.UTF8.GetString(plainBytes); } }逐项说明。关于密钥长度AES 的密钥长度必须是 16 字节128 位、24 字节192 位或者 32 字节256 位三者之一。上面代码里aes.Key通过Encoding.UTF8.GetBytes(key)得到字节数组所以 key 字符串的长度必须对应为 16、24、32 个字符。用 16 个字符就是 128 位密钥用 32 个字符就是 256 位密钥。超过 32 个字符也不会被截断而是直接抛异常这是新手最常遇到的问题。关于 IVIV 叫初始化向量长度固定等于 AES 的分组大小也就是 16 字节。不管密钥是 128 位还是 256 位IV 永远是 16 字节。IV 的作用是让同样的明文、同样的密钥也能产生不同的密文避免加密结果出现明显的模式泄露。如果 IV 固定不变本质上就削弱了 CBC 模式的安全性。关于填充模式AES 是分组加密算法每组 16 字节。如果明文长度不是 16 的倍数就需要填充。PaddingMode.PKCS7是最常见的选择加密时自动补齐解密时自动去掉。如果你用 NoPadding就必须保证明文长度恰好是 16 的倍数否则直接报错实际项目中几乎不会这么用。关于输出格式我把密文用 Base64 转成了字符串。Base64 的作用是把任意二进制字节数组转换成可见字符方便存数据库、放 JSON、传 URL。解密时先反 Base64 拿到原始密文再执行解密。关于模式选择CBC 模式是主流默认。ECB 模式虽然实现简单但相同的明文分组会生成相同的密文分组等于把明文的统计特征保留了下来属于安全设计上的减分项我明确建议不要用。2.3 非对称加密RSA 的加解密实现RSA 在 C# 里的 API 也很直接。我用它做过一个场景前端登录时用后端下发的 RSA 公钥加密密码后端用私钥解密。这样密码不会在传输链路里出现明文。生成密钥对的代码public static (string PublicKey, string PrivateKey) RsaGenerateKeys(int keySize 2048) { using (RSA rsa RSA.Create(keySize)) { return (rsa.ToXmlString(false), rsa.ToXmlString(true)); } }公钥和私钥都用 XML 字符串表示公钥可以对外分发私钥必须保存在服务端。密钥长度建议至少 2048 位1024 位在当下已经不够安全。RSA 加密和解密public static string RsaEncrypt(string publicKey, string plainText) { using (RSA rsa RSA.Create()) { rsa.FromXmlString(publicKey); byte[] plainBytes Encoding.UTF8.GetBytes(plainText); byte[] cipherBytes rsa.Encrypt(plainBytes, RSAEncryptionPadding.OaepSHA256); return Convert.ToBase64String(cipherBytes); } } public static string RsaDecrypt(string privateKey, string cipherText) { using (RSA rsa RSA.Create()) { rsa.FromXmlString(privateKey); byte[] cipherBytes Convert.FromBase64String(cipherText); byte[] plainBytes rsa.Decrypt(cipherBytes, RSAEncryptionPadding.OaepSHA256); return Encoding.UTF8.GetString(plainBytes); } }注意RSA 的加密输入长度有硬性上限。2048 位 RSA 最多只能加密大约 214 个字节的数据如果输入超过这个长度就会抛异常。所以 RSA 不适合直接加密长文本它更适合加密密钥这类短数据。我在实际项目里经常用RSA AES混合方案先用 RSA 加密一个随机生成的 AES 密钥再用这个 AES 密钥加密真实业务数据两全其美。另外FromXmlString在 .NET Core 3.0 之后可用如果你用的还是 .NET Framework也可以用相同的方法注意两者生成的 XML 格式略有差别跨平台对接时最好提前约定密钥格式。3. 完整工具类源码与实战用法3.1 一个可以直接用的加密工具类把上面这些功能打包成一个工具类是我在项目里的标准做法。统一入口方便调用也让团队成员不会各自写一套风格迥异的加密代码。using System; using System.Security.Cryptography; using System.Text; public static class CryptoUtil { private static readonly Encoding Enc Encoding.UTF8; // ---------- Base64 ---------- public static string Base64Encode(string input) Convert.ToBase64String(Enc.GetBytes(input)); public static string Base64Decode(string input) Enc.GetString(Convert.FromBase64String(input)); // ---------- 哈希 ---------- public static string Md5(string input) { using (MD5 md5 MD5.Create()) { byte[] hash md5.ComputeHash(Enc.GetBytes(input)); return Convert.ToHexString(hash).ToLower(); } } public static string Sha256(string input) { using (SHA256 sha256 SHA256.Create()) { byte[] hash sha256.ComputeHash(Enc.GetBytes(input)); return Convert.ToHexString(hash).ToLower(); } } // ---------- AES ---------- public static string AesEncrypt(string plainText, string key, string iv) { using (Aes aes Aes.Create()) { aes.Mode CipherMode.CBC; aes.Padding PaddingMode.PKCS7; aes.Key Enc.GetBytes(key); aes.IV Enc.GetBytes(iv); ICryptoTransform encryptor aes.CreateEncryptor(); byte[] plainBytes Enc.GetBytes(plainText); byte[] cipherBytes encryptor.TransformFinalBlock(plainBytes, 0, plainBytes.Length); return Convert.ToBase64String(cipherBytes); } } public static string AesDecrypt(string cipherText, string key, string iv) { using (Aes aes Aes.Create()) { aes.Mode CipherMode.CBC; aes.Padding PaddingMode.PKCS7; aes.Key Enc.GetBytes(key); aes.IV Enc.GetBytes(iv); ICryptoTransform decryptor aes.CreateDecryptor(); byte[] cipherBytes Convert.FromBase64String(cipherText); byte[] plainBytes decryptor.TransformFinalBlock(cipherBytes, 0, cipherBytes.Length); return Enc.GetString(plainBytes); } } // ---------- RSA ---------- public static (string PublicKey, string PrivateKey) RsaGenerateKeys(int keySize 2048) { using (RSA rsa RSA.Create(keySize)) { return (rsa.ToXmlString(false), rsa.ToXmlString(true)); } } public static string RsaEncrypt(string publicKey, string plainText) { using (RSA rsa RSA.Create()) { rsa.FromXmlString(publicKey); byte[] plainBytes Enc.GetBytes(plainText); byte[] cipherBytes rsa.Encrypt(plainBytes, RSAEncryptionPadding.OaepSHA256); return Convert.ToBase64String(cipherBytes); } } public static string RsaDecrypt(string privateKey, string cipherText) { using (RSA rsa RSA.Create()) { rsa.FromXmlString(privateKey); byte[] cipherBytes Convert.FromBase64String(cipherText); byte[] plainBytes rsa.Decrypt(cipherBytes, RSAEncryptionPadding.OaepSHA256); return Enc.GetString(plainBytes); } } }这个工具类我建议直接放进项目的公共类库所有业务层统一调用。把编码统一成 UTF-8把输出统一成 Base64把哈希结果统一成小写十六进制这些看似细节的约定能避免很多跨模块联调问题。3.2 典型业务场景接口签名与敏感字段加密工具类不是拿来摆着看的真正要落到业务里才有价值。我挑两个最常见的场景说说。第一个是接口签名。前后端联调时为了防止参数在传输途中被篡改通常会对请求参数做签名校验。做法是把关键参数拼接成字符串加上一个双方约定的密钥然后计算 Sha256 得到签名值。后端收到请求后用同样的规则重新计算一遍比对签名是否一致。这样只要密钥不泄露参数被改过就一定会导致签名不匹配。签名拼接的时候有一个小坑参数顺序不一致导致拼接结果不同签名验证失败。我一般先把参数按字典序排序拼接时用连接最后统一用Sha256方法计算。这套规则要写进接口文档前后端严格对齐。第二个是敏感字段加密存储。用户手机号、身份证号、银行卡号这类数据入库前用 AES 加密查询时再解密展示。在数据库设计时密文字段直接用TEXT类型长度比明文长不少。比如 11 位手机号AES 加密加 Base64 编码后大概变成 44 个字符左右设计字段时留够余量。这里有一个需要提前想清楚的问题AES 加密需要密钥和 IV。如果每个字段用同一个密钥同一个 IV那么相同明文的密文也相同攻击者可以通过分析密文分布来推断业务规律。更稳妥的做法是每条数据随机生成 IV然后跟密文一起存储。我常用的存储格式是Base64(IV) : Base64(密文)解密时先把 IV 取出来再用同一个密钥去解。这样每条记录的密文都不一样安全性上了一个台阶。3.3 进阶PBKDF2 派生密钥与随机 IV很多人图省事直接把密钥写成字符串硬编码在代码里。这样做的最大问题是一旦源码泄露所有加密数据等于裸奔。比较推荐的方案是用 PBKDF2 从口令派生出真正的密钥字节再用随机 IV 加密每一段数据。派生密钥的方法前面已经给了实际使用时可以这样组织流程// 第一步随机生成盐 byte[] salt RandomNumberGenerator.GetBytes(16); // 第二步从用户口令派生AES密钥32字节 256位 byte[] aesKey DerivePasswordKey(password, salt, iterations: 10000); // 第三步随机生成IV byte[] iv RandomNumberGenerator.GetBytes(16); // 第四步使用aesKey和iv加密最终存储salt iv cipherText注意盐和密钥不能混为一谈。盐可以随密文一起存储它的作用是防止同一个口令派生出的密钥总是唯一密钥才是真正需要保密的。IV 也可以随密文存储它的作用是让相同明文产生不同密文。只要密钥不泄露盐和 IV 暴露出去不会直接威胁数据安全。这套做法的标准术语叫加密盐随机 IV它比固定密钥固定 IV安全得多也是我实际项目里给客户做交付时的默认配置。4. 常见问题与排查技巧4.1 中文乱码的坑字符串加解密碰到中文乱码十有八九是编码不一致导致的。我给外部系统对接时碰到过一次对方用 GBK 编码加密我用 UTF-8 解密结果解出来的全是乱码。加密和解码两端的Encoding必须严格一致最简单的办法就是统一用Encoding.UTF8。另外一个隐蔽的坑是 C# 的Encoding.Default在不同平台上默认值不一样。在 Windows 上可能是 GBK在 Linux 上就是 UTF-8。代码里一旦用了Encoding.Default换台机器跑结果就变了。所以我的原则是所有加解密相关代码明确写Encoding.UTF8不依赖任何系统默认值。4.2 密钥长度不匹配与填充错误AES 最常见的异常就是 Specified key is not a valid size for this algorithm 以及 Padding is invalid and cannot be removed。第一种异常基本可以断定是密钥字节长度不对。排查步骤很简单先打印Encoding.UTF8.GetBytes(key).Length看看是不是 16、24、32 中的一个。中文密钥尤其容易踩坑因为一个中文字符在 UTF-8 下占 3 个字节我是密钥总共 4 个字符却是 12 个字节根本不够 16 字节的 AES 密钥长度。解决方案要么用固定长度的 ASCII 密钥要么用 PBKDF2 把任意长度的口令派生为固定长度的密钥字节。第二种异常 Padding is invalid字面意思是填充校验失败。常见原因有三个密钥不对、IV 不对、密文被篡改或截断。AES 的 PKCS7 填充在解密时会校验最后一组字节是否符合规则如果密钥错了解密出来的内容是乱的填充校验自然失败。排查思路是先用一组简单的数据已知密钥跑通加解密再把真实密钥和 IV 放回去验证基本能定位是哪一环出了问题。4.3 Base64 在 URL 传输中被截断Base64 编码结果里可能出现、/、这三种特殊字符。在 URL 传输时会被解析成空格/会影响路径语义会被部分框架当成参数分隔符。如果你要把密文放在 URL 里传递最好做 URL 安全处理。我常用的处理是替换字符public static string Base64UrlEncode(string input) Base64Encode(input).Replace(, -).Replace(/, _).TrimEnd(); public static string Base64UrlDecode(string input) { string b64 input.Replace(-, ).Replace(_, /); switch (b64.Length % 4) { case 2: b64 ; break; case 3: b64 ; break; } return Base64Decode(b64); }换成-/换成_去掉。解码的时候再反向替换回去同时根据长度补回。这个技巧在对接微信支付等外部接口时特别实用它们的签名串用的就是这种 URL 安全的 Base64 变体。4.4 性能与安全性的平衡RSA 加密长度受限、性能差AES 性能好但密钥分发难。实际项目中我维护过一个经验值加密 1KB 以内的数据RSA 的耗时在几毫秒到几十毫秒之间AES 则是微秒级。如果需要加密的数据量很大直接上 AES如果需要多人协作分发数据就用 RSA 加密 AES 密钥的混合方案。安全性和可维护性也需要取舍。把密钥写在配置文件里是不是完全不行也不是绝对不行关键看你面对什么威胁模型。如果是内部系统的配置文件加上文件权限控制和环境变量注入已经能满足大部分场景。但如果是面向公网的核心服务密钥管理最好独立出来用专门的密钥管理服务或者至少用IConfiguration配合环境变量覆盖。我个人的习惯是代码里绝对不出现任何真实密钥密钥通过环境变量注入并提供一份.env.example或者配置模板给同事参考。这样即使代码仓库泄露敏感数据也不会跟着泄露。5. 实操心得与建议做加解密这块时间久了越来越觉得不犯错比炫技重要得多。下面这些心得是我踩过几次坑之后沉淀下来的。第一永远不要在代码里写死密钥。哪怕是内部工具也要养成从配置读取的习惯。你永远不知道代码会被复制到哪里、仓库会被推送到哪个平台密钥一旦进了 Git 历史再想清理就非常被动了。第二优先使用 .NET 自带的加密库不要自己实现算法。写一个看起来能跑的自制加密并不难难的是保证它在各种边界条件下都安全可靠。内置的Aes、RSA、SHA256已经经过了大量安全审计直接用比自研靠谱得多。第三加密方案一定要留有升级的余地。我见过不少项目第一版用 MD5 存密码上线两年后想迁移到 PBKDF2结果因为历史数据解不开而卡壳。比较好的做法是存储时带上算法标识比如字段值前面加个前缀PBKDF2$10000$salt$hash这样以后升级算法规则老数据还能平滑迁移。第四测试用例要覆盖中文、空字符串、特殊字符、超长字符串四种情况。空字符串和 null 在加解密方法里的处理逻辑很容易被忽略我在工具类里统一做了空值判断返回空字符串避免上层业务拿到 null 后引发连锁异常。第五前后端联调时把密钥长度、IV 长度、编码格式、CBC 模式、PKCS7 填充、Base64 输出所有这些参数写进接口文档。这六个参数缺一个两边就对不上。我吃过一次亏前端说加密了后端说解密失败调试了半天才发现是两端 IV 长度一个是 16 字节一个是 8 字节。字符串加解密看起来是个小功能但涉及的细节真不少。C# 的加密 API 用起来简单真正考验人的是对每种算法适用场景的理解和参数的严谨把控。把基础方案吃透再根据自己的业务场景做调整你的代码就不会在加密这块掉链子。

C#字符串加解密实战：AES、RSA与SHA-256工具类详解

相关推荐

STM32F4+HAL库驱动SHT25温湿度传感器：I2C时序与CRC-8校验

安全顶会论文泛读指南：从NDSS 2021看物联网与模糊测试等方向

Claude Opus 4.6自主推理实测：从代码修复到数据清洗的深度评测

更多资讯

A-29P宽压供电架构：4V~16.5V电压域的功耗与权衡A-59F是一款重新设计并全面升级的多功能语音处理模组，集成了本地扩音防啸叫、AI智能降噪、全双工回音消除以及双麦波束成形四大核心功能。该模组

【合规领域】【信息科学与工程学】计算机科学与自动化——第五百篇国产化/XC解决方案第二篇海光CPU/DCU芯片适配02

从零复现tinyllama-colorist-lora：基于TinyLlama-1.1B-Chat的LoRA微调实操指南

tf_mixnet_s.in1k项目全景概览：4.1M参数轻量级图像分类模型（MixNet架构）到底强在哪？

戴森球计划FactoryBluePrints：工厂蓝图速通指南

4-1-Computer Class Built-in Variables-sysBootTime

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

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

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

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

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