本文还有配套的精品资源，点击获取

简介：C#个人账户管理系统源码是一个基于C#语言开发的综合性项目，旨在实现用户注册、登录、账户信息管理、交易记录查询和余额查询等核心功能。系统采用Visual Studio 2008作为开发环境，结合C# 3.0与LINQ技术，利用ADO.NET进行数据库操作，并通过WinForm或WPF构建用户界面。项目涵盖密码加密、用户验证、异常处理、日志记录等关键模块，融合了面向对象设计模式与安全编程实践。本源码解析帮助开发者深入掌握C#在实际业务系统中的应用，提升全栈开发能力。

C#账户系统核心机制与安全架构深度实践

在金融类软件开发中，一个稳健的个人账户管理系统不仅是功能实现的问题，更是对语言特性、数据安全、业务逻辑和用户体验的综合考验。我们今天要探讨的，不是“如何写一个银行程序”这种表层话题，而是—— 如何用C#构建一个真正经得起生产环境锤炼、具备高安全性与可维护性的账户系统 。

想象这样一个场景：凌晨两点，运维报警电话响起，某用户反馈“我刚转账失败但钱被扣了”，而日志显示数据库事务回滚正常。深入排查后发现，是前端重复提交 + 后端幂等性缺失导致的资金状态不一致。这类问题，在缺乏严谨设计的系统中屡见不鲜。

所以，今天我们不讲教科书式的Demo，我们要从真实世界的挑战出发，一步步拆解C#在账户系统中的关键应用：类型安全如何防止金融计算灾难？ADO.NET底层连接池怎样支撑高并发？SHA256+盐值真的够安全吗？WinForm界面也能做到纵深防御？

准备好了吗？Let’s dive in！🚀

---

类型为王：C#的类型系统是如何守护金融数据命脉的？

先问一个问题：你有没有见过这样的bug？

double balance = 1000.0;
balance -= 999.99; // 结果是多少？
Console.WriteLine(balance); // 输出：0.010000000000000231 😱

这不是玄学，这是浮点数精度丢失的经典案例。而在账户系统里，哪怕差一分钱，都是不可接受的事故。

decimal：专为金钱而生的数据类型

C# 提供了 decimal 类型，它采用 128 位定点数表示法，专为财务计算设计：

decimal balance = 1000.00m; // 注意末尾的 'm'
balance -= 999.99m;
Console.WriteLine(balance); // 输出：0.01 —— 正确！✅

💡 小知识： m 是 literal suffix，告诉编译器这是一个 decimal 字面量，而不是 double。

但这还不够。如果用户试图存入 -500 元呢？或者余额溢出到负数？我们需要更进一步的防护。

checked 上下文：让整数溢出变成异常

考虑以下代码：

int a = int.MaxValue;
int b = a + 1; // 溢出了，结果会变成 -2147483648（绕回）

在某些极端情况下（比如恶意构造大额交易），这可能导致严重的逻辑漏洞。C# 提供了 checked 关键字来捕获这种溢出：

try
{
    checked
    {
        int result = int.MaxValue + 1; // 抛出 OverflowException
    }
}
catch (OverflowException)
{
    throw new InvalidOperationException("交易金额超出系统支持范围");
}

你甚至可以在项目级别开启全局检查：

<PropertyGroup>
  <CheckForOverflowUnderflow>true</CheckForOverflowUnderflow>
</PropertyGroup>

这样一来，所有算术操作都会自动进行溢出检测，虽然性能略有损耗，但在金融系统中这笔代价值得付出。

面向对象封装：把敏感字段锁进“保险柜”

再看这个简单的 Account 类：

public class Account
{
    private decimal _balance;

    public void Deposit(decimal amount)
    {
        if (amount <= 0) 
            throw new ArgumentException("存款金额必须大于零");

        _balance += amount;
    }

    public void Withdraw(decimal amount)
    {
        if (amount <= 0) 
            throw new ArgumentException("取款金额必须大于零");

        if (_balance < amount)
            throw new InvalidOperationException("余额不足");

        _balance -= amount;
    }

    public decimal GetBalance() => _balance; // 只读暴露
}

这里有几个精妙的设计点：

• 私有字段 _balance ：外部无法直接修改，杜绝了“余额篡改”类漏洞。
• 方法级校验 ：每一笔操作都自带合法性验证。
• 只读访问器 ：避免暴露 setter 导致意外赋值。

而且，借助继承与多态，我们可以轻松扩展不同类型的账户：

public abstract class BankAccount
{
    protected decimal Balance { get; set; }
    public abstract void ApplyInterest(); // 不同账户利息策略不同
}

public class SavingsAccount : BankAccount
{
    public override void ApplyInterest()
    {
        Balance *= 1.03m; // 年化3%
    }
}

public class CheckingAccount : BankAccount
{
    public override void ApplyInterest()
    {
        Balance *= 1.005m; // 活期低息
    }
}

这种“高内聚、低耦合”的设计，正是面向对象思想在金融系统中的优雅体现。

至于命名空间组织？那简直是大型项目的救命稻草。试想一下，当你看到 BankSystem.Core.Accounting , BankSystem.Security.Authentication , BankSystem.Reporting.Export 这样的结构时，你会不会觉得心里特别踏实？

namespace BankSystem.Core.Entities
{
    public class Account { /* ... */ }
}

namespace BankSystem.Data.Access
{
    public class AccountRepository { /* ... */ }
}

清晰的分层不仅提升可读性，也为未来的模块化拆分打下基础——比如哪天想把安全认证独立成微服务，你会发现接口已经天然隔离好了。

---

数据库生死线：ADO.NET 如何扛住高频交易风暴？

如果说内存中的对象是“灵魂”，那数据库就是系统的“躯体”。没有稳定高效的数据持久化能力，再漂亮的UI也只是空中楼阁。

SqlConnection：不只是打开一个连接那么简单

我们都知道要用 using 来管理资源：

using (var conn = new SqlConnection(connectionString))
{
    conn.Open();
    // 执行命令...
} // 自动关闭并释放

但你知道背后发生了什么吗？

当你调用 conn.Open() 时，并不一定每次都建立新的 TCP 连接。.NET 默认启用了 连接池（Connection Pooling） ，它的行为就像这样：

graph TD
    A[应用程序请求连接] --> B{连接池中有可用连接?}
    B -- 是 --> C[复用现有连接]
    B -- 否 --> D[新建物理连接]
    C --> E[执行SQL命令]
    D --> E
    E --> F[命令执行完成]
    F --> G[连接返回池中待复用]

这意味着什么？意味着即使你的系统每秒处理上千次查询，实际建立的物理连接可能只有几十个。这对性能的提升是指数级的！

你可以通过连接字符串控制池行为：

Server=localhost;Database=AccountDB;User Id=sa;Password=xxx;
Max Pool Size=100;Min Pool Size=5;Connection Timeout=30;

但注意：别乱设最大值！连接太多反而拖垮数据库。

安全第一：加密配置文件，别让密码裸奔

很多人图省事，把密码明文写在 app.config 里：

<connectionStrings>
  <add name="AccountDB" 
       connectionString="Server=...;Password=MyPass123!" />
</connectionStrings>

一旦服务器被入侵，整个数据库就拱手相送了。

正确的做法是使用 DPAPI 加密：

aspnet_regiis.exe -pef "connectionStrings" "C:\YourAppPath"

执行后你会看到：

<connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">
  <EncryptedData>
    <!-- 一串看不懂的加密内容 -->
  </EncryptedData>
</connectionStrings>

只有在同一台机器上运行的应用才能解密，极大提升了安全性。

SqlCommand：参数化查询才是防注入的终极武器

来看一个经典的 SQL 注入攻击：

string sql = "SELECT * FROM Users WHERE Username = '" + txtUser.Text + "'";

用户输入 ' OR '1'='1 ，直接绕过登录验证。

解决方案？永远不要拼接字符串！用参数化查询：

string sql = "SELECT UserId, Balance FROM Users WHERE Username = @Username AND PasswordHash = HASHBYTES('SHA2_256', @Password)";

using (var cmd = new SqlCommand(sql, conn))
{
    cmd.Parameters.AddWithValue("@Username", username);
    cmd.Parameters.AddWithValue("@Password", password);

    using (var reader = cmd.ExecuteReader())
    {
        if (reader.Read())
        {
            return new User
            {
                UserId = reader.GetInt32("UserId"),
                Balance = reader.GetDecimal("Balance")
            };
        }
    }
}

这里的要点在于：

• 使用 @ParameterName 占位符，由数据库引擎解析；
• 参数值不会被当作 SQL 代码执行；
• 同时还能提高执行计划缓存命中率，加快响应速度。

顺便说一句，你在数据库端直接用 HASHBYTES('SHA2_256', ...) 对比密码，其实是有风险的——网络传输过程中仍是明文。理想做法是在客户端先哈希一次，再传给服务端二次哈希（即“双重哈希”或加盐处理），但我们后面会详细展开。

SqlDataAdapter + DataSet：离线操作的艺术

有些场景不需要实时连接数据库，比如展示一个月的交易记录报表。这时候可以使用“断开式”数据模型：

public DataSet GetTransactionHistory(int userId)
{
    string sql = "SELECT TxId, Amount, TxType, TxDate FROM Transactions WHERE UserId = @UserId";
    var ds = new DataSet();

    using (var conn = new SqlConnection(GetEncryptedConnectionString()))
    using (var adapter = new SqlDataAdapter(sql, conn))
    {
        adapter.SelectCommand.Parameters.AddWithValue("@UserId", userId);
        adapter.Fill(ds, "Transactions");
    }

    // 此时已无数据库连接，仍可操作数据
    foreach (DataRow row in ds.Tables["Transactions"].Rows)
    {
        row["Amount"] = Math.Round((decimal)row["Amount"], 2);
    }

    return ds;
}

然后前端可以直接绑定到 DataGridView ：

dataGridView.DataSource = ds.Tables["Transactions"];

这种方式的优点很明显：

特性	Connected ( DataReader )	Disconnected ( DataAdapter + DataSet )
连接保持	必须打开	查询后即可关闭
内存占用	极低（流式读取）	较高（整表加载）
编辑能力	只读	支持增删改查
适用场景	实时查询	报表、本地缓存

流程图如下：

flowchart LR
    A[发起查询请求] --> B[SqlDataAdapter执行Fill]
    B --> C[填充DataSet]
    C --> D[关闭数据库连接]
    D --> E[前端绑定数据显示]
    E --> F[用户编辑数据]
    F --> G[点击保存触发Update]
    G --> H[重新打开连接]
    H --> I[SqlDataAdapter提交变更]
    I --> J[事务提交或回滚]

特别是当你配合 CommandBuilder 自动生成 InsertCommand / UpdateCommand / DeleteCommand 时，几乎不用写额外 SQL 就能实现完整的 CRUD。

---

安全防线：从密码存储到业务逻辑的全面加固

现在进入重头戏—— 安全 。

很多开发者以为“用了 HTTPS 就万事大吉”，殊不知最大的漏洞往往藏在最不起眼的地方：密码怎么存的？失败登录有没有限制？转账有没有事务保护？

密码安全：SHA256 真的够用吗？

先看一段注册逻辑：

public static string ComputeSha256Hash(string rawData)
{
    using (SHA256 sha256 = SHA256.Create())
    {
        byte[] bytes = sha256.ComputeHash(Encoding.UTF8.GetBytes(rawData));
        var sb = new StringBuilder();
        foreach (byte b in bytes)
        {
            sb.Append(b.ToString("x2"));
        }
        return sb.ToString();
    }
}

看起来很专业，对吧？但如果你只做这一步，那你等于把密码存在“明文”水平。

为什么？因为彩虹表攻击可以轻松破解常见密码。

彩虹表攻击原理简析

攻击者事先计算好常见密码（如 123456 , password ）的 SHA256 值，做成一张巨大的查找表。一旦拿到数据库哈希值，直接查表就能还原原始密码。

解决办法？加盐（Salt）！

盐值（Salt）：每个用户独一无二的“指纹”

public static class PasswordHasher
{
    public static (string hash, string salt) HashPassword(string password)
    {
        byte[] saltBytes = new byte[32];
        using (var rng = RandomNumberGenerator.Create())
        {
            rng.GetBytes(saltBytes);
        }

        string salt = Convert.ToBase64String(saltBytes);
        string saltedPassword = password + salt;
        string hash = ComputeSha256Hash(saltedPassword);

        return (hash, salt);
    }

    public static bool VerifyPassword(string password, string storedHash, string storedSalt)
    {
        string saltedPassword = password + storedSalt;
        string computedHash = ComputeSha256Hash(saltedPassword);
        return computedHash.Equals(storedHash, StringComparison.OrdinalIgnoreCase);
    }
}

关键点：

• RandomNumberGenerator 是加密安全的随机源；
• Salt 长度 32 字节，提供足够熵；
• 每个用户的 Salt 不同，即使密码相同，哈希也完全不同。

Salt 类型	是否推荐	原因
固定全局 Salt	❌	所有用户共用，形同虚设
用户名作为 Salt	⚠️	有一定效果，但可预测
随机每用户 Salt	✅✅✅	最佳实践

不过……SHA256 太快了也是一个问题。现代 GPU 每秒能尝试上亿次哈希计算。所以更高级的做法是使用 bcrypt 或 Argon2 ，它们内置“慢速机制”，专门对抗暴力破解。

算法	推荐程度	说明
MD5	❌	已被破解
SHA1	❌	存在碰撞漏洞
SHA256	✅	安全，但需加盐+迭代
bcrypt	✅✅✅	强烈推荐，内置慢速
Argon2	✅✅✅✅	当前最强，2015年密码竞赛冠军

当然，如果你坚持用 SHA256，至少要做 PBKDF2（多次迭代）：

var pbkdf2 = new Rfc2898DeriveBytes(password, saltBytes, 10000); // 迭代1万次
byte[] hash = pbkdf2.GetBytes(256 / 8);

这才叫真正的“单向加密”。

AES 加密：保护身份证、手机号等敏感字段

除了密码，还有许多敏感信息需要保护，比如：

• 身份证号
• 手机号
• 邮箱地址
• 银行卡号

这些不能用哈希（因为需要还原），只能加密存储。

AES 是目前最主流的对称加密算法：

public class AesEncryptionHelper
{
    private static readonly byte[] Key = Encoding.UTF8.GetBytes("16ByteLongKey123"); // 128-bit
    private static readonly byte[] IV = Encoding.UTF8.GetBytes("16ByteInitVector");  // CBC模式所需

    public static string Encrypt(string plainText)
    {
        using (Aes aes = Aes.Create())
        {
            aes.Key = Key;
            aes.IV = IV;

            using (MemoryStream ms = new MemoryStream())
            using (CryptoStream cs = new CryptoStream(ms, aes.CreateEncryptor(), CryptoStreamMode.Write))
            using (StreamWriter sw = new StreamWriter(cs))
            {
                sw.Write(plainText);
                sw.Close();
                return Convert.ToBase64String(ms.ToArray());
            }
        }
    }

    public static string Decrypt(string cipherText)
    {
        using (Aes aes = Aes.Create())
        {
            aes.Key = Key;
            aes.IV = IV;

            using (MemoryStream ms = new MemoryStream(Convert.FromBase64String(cipherText)))
            using (CryptoStream cs = new CryptoStream(ms, aes.CreateDecryptor(), CryptoStreamMode.Read))
            using (StreamReader sr = new StreamReader(cs))
            {
                return sr.ReadToEnd();
            }
        }
    }
}

流程图如下：

graph TD
    A[明文数据] --> B{是否加密?}
    B -->|是| C[AES加密: 使用Key+IV]
    C --> D[生成密文字节流]
    D --> E[Base64编码]
    E --> F[存储至数据库]

    F --> G{是否解密?}
    G -->|是| H[Base64解码]
    H --> I[AES解密: 使用相同Key+IV]
    I --> J[恢复明文数据]
    J --> K[显示给授权用户]
    style C fill:#e0f7fa,stroke:#01579b
    style I fill:#e0f7fa,stroke:#01579b

⚠️ 重大提醒 ：永远不要硬编码 Key 和 IV！
应使用 Windows DPAPI、Azure Key Vault 或企业级 KMS 系统统一管理密钥。

否则，代码泄露 = 数据全丢。

登录失败锁定：防暴力破解的第一道屏障

设想一个脚本每秒尝试 100 个密码组合，不出几分钟就能撞开弱密码账户。

对策？引入失败次数限制：

public class LoginService
{
    private const int MaxAttempts = 5;
    private const int LockoutMinutes = 30;

    public bool ValidateUser(string username, string password)
    {
        var user = _dataAccess.GetUserByUsername(username);
        if (user == null) return false;

        // 检查是否被锁定
        if (user.LockoutUntilUtc.HasValue && user.LockoutUntilUtc > DateTime.UtcNow)
        {
            throw new InvalidOperationException("账户已被锁定，请稍后再试。");
        }

        bool isValid = PasswordHasher.VerifyPassword(password, user.PasswordHash, user.Salt);
        if (!isValid)
        {
            int newAttemptCount = user.FailedLoginAttempts + 1;
            if (newAttemptCount >= MaxAttempts)
            {
                _dataAccess.LockUserAccount(username, DateTime.UtcNow.AddMinutes(LockoutMinutes));
                LogSecurityEvent($"用户 {username} 因多次失败被锁定", EventType.Warning);
            }
            else
            {
                _dataAccess.IncrementFailedAttempts(username);
            }
            return false;
        }

        // 成功则重置
        _dataAccess.ResetFailedAttempts(username);
        LogSecurityEvent($"用户 {username} 登录成功", EventType.Info);
        return true;
    }
}

数据库字段建议：

字段	类型	说明
FailedLoginAttempts	tinyint	当前失败次数
LockoutUntilUtc	datetime	锁定截止时间（UTC）

这样即使有人写脚本爆破，最多试 5 次就会被锁 30 分钟，大大增加攻击成本。

转账事务：ACID 如何拯救世界

最后，来看看最危险的操作——转账。

假设你要从 A 账户转 500 元到 B 账户，步骤如下：

1. 检查 A 余额 ≥ 500
2. A 扣款 500
3. B 增加 500
4. 记录交易日志

如果第 3 步失败了怎么办？A 的钱没了，B 没收到。这就是典型的“部分更新”问题。

答案只有一个： 数据库事务

public void TransferFunds(int fromAccountId, int toAccountId, decimal amount)
{
    if (amount <= 0) 
        throw new ArgumentException("金额必须大于零。");

    using (var conn = new SqlConnection(connectionString))
    {
        conn.Open();
        using (var tran = conn.BeginTransaction())
        {
            try
            {
                // 1. 检查余额
                decimal currentBalance = _dataAccess.GetBalance(fromAccountId, conn, tran);
                if (currentBalance < amount)
                    throw new InvalidOperationException("余额不足。");

                // 2. 扣款
                _dataAccess.DeductFunds(fromAccountId, amount, conn, tran);

                // 3. 加款
                _dataAccess.AddFunds(toAccountId, amount, conn, tran);

                // 4. 记录日志
                _dataAccess.LogTransaction(fromAccountId, toAccountId, amount, conn, tran);

                // 所有成功，提交事务
                tran.Commit();
            }
            catch
            {
                tran.Rollback(); // 任何错误都回滚
                throw; // 继续向上抛出异常
            }
        }
    }
}

这才是真正的 ACID：

• 原子性（Atomicity） ：要么全部成功，要么全部失败；
• 一致性（Consistency） ：转账前后总金额不变；
• 隔离性（Isolation） ：并发转账不会互相干扰；
• 持久性（Durability） ：一旦提交，永久生效。

千万别忘了在 catch 中 throw; 而不是 throw ex; ，否则会破坏堆栈跟踪信息！

LINQ to DataSet：让数据分析变得优雅

对于历史交易分析，可以用 LINQ 快速筛选：

public DataTable GetMonthlyTransactions(DataSet ds, int accountId, int year, int month)
{
    var results = from row in ds.Tables["Transactions"].AsEnumerable()
                  where row.Field<int>("AccountId") == accountId &&
                        row.Field<DateTime>("TxDate").Year == year &&
                        row.Field<DateTime>("TxDate").Month == month
                  select row;

    return results.Any() ? results.CopyToDataTable() : new DataTable();
}

语法简洁，类型安全，还支持 IntelliSense，简直是数据分析师的好朋友 ❤️。

---

异常处理：写出让人安心的代码

没人希望自己的系统崩了还要靠重启救场。好的异常处理机制，能让系统在风雨中依然屹立不倒。

多层 catch：精准定位问题根源

try
{
    using (var cmd = new SqlCommand(query, connection))
    {
        connection.Open();
        using (var reader = cmd.ExecuteReader())
        {
            while (reader.Read()) { /* 处理数据 */ }
        }
    }
}
catch (SqlException ex) when (ex.Number == 18456)
{
    throw new InvalidLoginException("数据库登录失败，请检查凭据。", ex);
}
catch (SqlException ex) when (ex.Number == -2)
{
    throw new ConnectionTimeoutException("数据库连接超时，请稍后重试。", ex);
}
catch (IOException ex)
{
    EventLog.WriteEntry("AccountSystem", $"I/O错误: {ex.Message}", EventLogEntryType.Error);
    throw;
}
finally
{
    if (connection?.State == ConnectionState.Open)
        connection.Close();
}

看到了吗？我们根据 SqlException.Number 区分具体错误类型，并包装成自定义异常，便于上层针对性处理。

自定义异常：让你的错误会说话

public class InvalidLoginException : Exception
{
    public InvalidLoginException() { }
    public InvalidLoginException(string message) : base(message) { }
    public InvalidLoginException(string message, Exception inner) : base(message, inner) { }
}

public class ConnectionTimeoutException : Exception
{
    public ConnectionTimeoutException(string message) : base(message) { }
}

比起泛泛的 Exception ，这些异常能让调用方清楚知道发生了什么。

finally vs using：双重保障资源释放

尽管 using 已经很强大，但在复杂逻辑中，加上 finally 是一种良好的防御性编程习惯：

graph LR
    A[开始执行] --> B[try: 执行数据库操作]
    B --> C{是否异常?}
    C -->|是| D[catch: 捕获并处理]
    C -->|否| E[正常结束]
    D --> F[finally: 关闭连接]
    E --> F
    F --> G[方法退出]

确保无论发生什么，连接都能安全关闭。

---

UI 层安全：WinForm 也能构筑铜墙铁壁

很多人认为“安全是后台的事”，其实前端也是攻击入口。

数据绑定：安全又高效的展示方式

private void LoadTransactionData(string userId)
{
    try
    {
        DataSet ds = TransactionDAL.GetTransactionsByUser(userId);
        dataGridViewTransactions.DataSource = ds.Tables["Transactions"];
        dataGridViewTransactions.ReadOnly = true; // 防止误编辑
        dataGridViewTransactions.AutoResizeColumns();
    }
    catch (Exception ex)
    {
        MessageBox.Show("加载失败：" + ex.Message, "错误", MessageBoxButtons.OK, MessageBoxIcon.Error);
    }
}

ReadOnly = true 很关键，避免用户不小心改了数据却不知道没保存。

输入控制：MaskedTextBox 防呆设计

<MaskedTextBox Name="txtPhone" Mask="(999) 000-0000" />
<MaskedTextBox Name="txtCardNumber" Mask="0000-0000-0000-0000" />

强制格式输入，既提升体验，又减少非法数据进入系统的可能。

动态权限控制：未登录看不到转账按钮

private void ShowAccountPanel()
{
    btnTransfer.Enabled = true;
    btnWithdraw.Enabled = true;
    groupBoxHistory.Visible = true;
    tabControlMain.TabPages.Add(tabAccountSettings);
}

连按钮都不显示，从根本上杜绝越权操作。

ContextMenuStrip 禁用右键复制

dataGridViewTransactions.ContextMenuStrip = null; // 禁用右键菜单

防止用户复制敏感信息到剪贴板，降低数据泄露风险。

---

日志监控：让一切操作都有迹可循

最后，别忘了日志。没有日志的系统，就像没有黑匣子的飞机。

Windows 事件日志：关键动作留痕

public static void LogLoginAttempt(string username, bool success)
{
    string source = "PersonalAccountSystem";
    if (!EventLog.SourceExists(source))
        EventLog.CreateEventSource(source, "Application");

    EventLog.WriteEntry(
        source,
        $"用户 [{username}] 登录尝试 - {(success ? "成功" : "失败")}",
        success ? EventLogEntryType.Information : EventLogEntryType.Warning,
        1001
    );
}

这些日志会被 SIEM 系统采集，用于安全审计与威胁检测。

文件日志 + 脱敏处理

生产环境建议写文件日志，并对敏感信息脱敏：

public static void WriteSecureLog(string message)
{
    string sanitized = Regex.Replace(message, @"(\d{4})\d{8}(\d{4})", "$1**** ****$2");
    string logFile = $"logs\\{DateTime.Today:yyyyMMdd}.log";
    string line = $"{DateTime.Now:yyyy-MM-dd HH:mm:ss} | {sanitized}";
    File.AppendAllText(logFile, line + Environment.NewLine);
}

日志级别建议：

级别	使用场景
Fatal	系统崩溃
Error	操作失败
Warning	登录失败
Info	成功操作
Debug	参数输出
Trace	变量变化

完整监控链条：

graph TD
    A[用户操作] --> B{是否为敏感操作?}
    B -->|是| C[写入EventLog]
    B -->|否| D[写入本地日志文件]
    C --> E[SIEM系统采集]
    D --> F[定时压缩归档]
    F --> G[删除7天前日志]
    E --> H[安全团队告警分析]

---

写在最后：技术之外的思考 🤔

我们聊了很多技术细节： decimal 、 SqlConnection 、 SHA256+Salt 、事务、日志……

但真正决定一个系统成败的，往往不是某一行代码，而是 设计哲学 。

• 你是选择“快速上线再说”，还是“先把安全做好”？
• 你是相信“用户不会乱操作”，还是默认“所有人都可能是攻击者”？
• 你写的代码，是给自己看的，还是给五年后的维护者看的？

记住一句话： 在金融系统中，没有“差不多”这三个字 。

每一个小数点，每一次数据库连接，每一条日志记录，都在默默守护着用户的信任。

而这，才是我们作为开发者最大的荣耀。✨

本文还有配套的精品资源，点击获取

简介：C#个人账户管理系统源码是一个基于C#语言开发的综合性项目，旨在实现用户注册、登录、账户信息管理、交易记录查询和余额查询等核心功能。系统采用Visual Studio 2008作为开发环境，结合C# 3.0与LINQ技术，利用ADO.NET进行数据库操作，并通过WinForm或WPF构建用户界面。项目涵盖密码加密、用户验证、异常处理、日志记录等关键模块，融合了面向对象设计模式与安全编程实践。本源码解析帮助开发者深入掌握C#在实际业务系统中的应用，提升全栈开发能力。

本文还有配套的精品资源，点击获取