核心区别：一维 vs 二维

最本质的区别在于：

• Flexbox：一维布局系统，适合处理行或列方向的排列
• Grid：二维布局系统，同时控制行和列的精确定位

这不是说 Flexbox 不能做二维布局，而是 Grid 在二维场景下更加优雅和高效。

实战案例 1：导航栏布局

导航栏是典型的一维布局场景，Flexbox 是最佳选择：

.navbar {
  display: flex;
  justify-content: space-between;
  align-items: center;
  padding: 1rem 2rem;
}

.nav-links {
  display: flex;
  gap: 2rem;
  list-style: none;
}

.nav-links li {
  white-space: nowrap;
}

/* 响应式：小屏幕垂直排列 */
@media (max-width: 768px) {
  .navbar {
    flex-direction: column;
    gap: 1rem;
  }
}

为什么用 Flexbox？

• 导航项按单一方向排列
• gap 属性自动处理间距
• flex-direction 轻松切换横竖布局

实战案例 2：卡片网格布局

产品列表、图片墙等网格场景，Grid 完胜：

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
  gap: 2rem;
  padding: 2rem;
}

.card {
  background: white;
  border-radius: 8px;
  overflow: hidden;
  box-shadow: 0 2px 8px rgba(0,0,0,0.1);
}

Grid 的优势：

• auto-fit + minmax 实现完美自适应，无需媒体查询
• 自动填充空间，每个卡片宽度一致
• 比 Flexbox 的 flex-wrap 方案更可控

实战案例 3：复杂页面布局

圣杯布局（Header + Sidebar + Main + Footer）是 Grid 的杀手级应用：

.app-layout {
  display: grid;
  grid-template-areas:
    "header header header"
    "sidebar main aside"
    "footer footer footer";
  grid-template-columns: 250px 1fr 300px;
  grid-template-rows: auto 1fr auto;
  min-height: 100vh;
}

.header  { grid-area: header; }
.sidebar { grid-area: sidebar; }
.main    { grid-area: main; }
.aside   { grid-area: aside; }
.footer  { grid-area: footer; }

/* 响应式：小屏幕单列布局 */
@media (max-width: 1024px) {
  .app-layout {
    grid-template-areas:
      "header"
      "main"
      "aside"
      "footer";
    grid-template-columns: 1fr;
  }
}

Grid 的语义化优势：

• grid-template-areas 让布局结构一目了然
• 调整布局只需改变 areas 定义，无需修改 HTML
• 轻松实现复杂的跨行跨列效果

高级技巧：Grid + Flexbox 组合

真正的高手懂得组合使用两者。典型场景：Grid 定义整体框架，Flexbox 处理内部细节。

/* Grid 控制整体布局 */
.dashboard {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 1.5rem;
}

/* Flexbox 处理卡片内部对齐 */
.widget {
  display: flex;
  flex-direction: column;
  padding: 1.5rem;
  background: white;
  border-radius: 8px;
}

.widget-header {
  display: flex;
  justify-content: space-between;
  align-items: center;
  margin-bottom: 1rem;
}

.widget-content {
  flex: 1; /* 占据剩余空间 */
}

.widget-footer {
  margin-top: auto; /* 推到底部 */
  padding-top: 1rem;
  border-top: 1px solid #eee;
}

性能考量

两者的渲染性能相当，但有细微差异：

决策树：如何选择？

需要二维精确定位？
├─ 是 CSS Grid
└─ 否
   |
   需要内容自适应宽度？
   ├─ 是 Flexbox (justify-content)
   └─ 否
      |
      需要复杂的对齐控制？
      ├─ 是 Flexbox (align-items/self)
      └─ 否 看具体需求，两者皆可

浏览器兼容性

• Flexbox：IE 10+ （需要前缀）
• Grid：IE 11+（部分支持，需要旧语法）、现代浏览器完全支持
• 生产环境建议使用 Autoprefixer 自动处理兼容性

总结

掌握 Grid 和 Flexbox 的核心原则：

• Flexbox：内容驱动布局，适合组件内部细节排列
• Grid：结构驱动布局，适合页面级框架搭建
• 组合使用：Grid 定框架，Flexbox 调细节

不要陷入”只用其一”的误区，根据场景灵活选择才是专业开发者的标志。实际项目中，80% 的布局问题都可以用这两个工具优雅解决，无需依赖第三方框架。

（本文基于 CSS3 最新规范和现代浏览器最佳实践整理，适合有一定 CSS 基础的开发者深入学习）

async/await 基础回顾

async 和 await 是语法糖，编译器会将它们转换为状态机。关键点在于：

• async 方法：返回 Task 或 Task<T>，调用时不会阻塞线程
• await 表达式：等待任务完成，期间释放线程
• ConfigureAwait(false)：跨线程上下文优化性能

// 基础异步方法
public async Task<User> GetUserAsync(int id)
{
    var user = await _userRepository.FindByIdAsync(id);
    return user;
}

// 库代码中的最佳实践
public async Task<IEnumerable<User>> GetAllUsersAsync()
{
    var users = await _userRepository.GetAllAsync()
        .ConfigureAwait(false); // 不需要同步上下文
    return users;
}

常见陷阱与解决方案

1. 死锁问题

// ❌ 危险：在 UI 线程或 ASP.NET 同步上下文中调用
var user = GetUserAsync(id).Result; // 可能死锁！

// ✅ 安全：始终使用 await
var user = await GetUserAsync(id);

2. 异常处理

// ❌ 错误：异常被吞掉
try
{
    await Task.Run(() => { throw new Exception("Oops"); });
}
finally
{
    // 这里捕获不到异常
}

// ✅ 正确：多个任务并行，统一处理异常
var tasks = new List<Task>
{
    Task1Async(),
    Task2Async(),
    Task3Async()
};

try
{
    await Task.WhenAll(tasks);
}
catch (Exception ex)
{
    // 只能看到第一个异常
    Console.WriteLine($"Exception: {ex.Message}");
}

3. void 返回类型

// ❌ 避免：async void 方法
public async void BadMethod()
{
    await Task.Delay(1000);
    // 异常无法被外部捕获！
}

// ✅ 推荐：使用 Task 返回类型
public async Task GoodMethod()
{
    await Task.Delay(1000);
    // 异常可以被 await 或 .Result 捕获
}

性能优化技巧

1. 避免不必要的 async

// ❌ 浪费：不需要 async
public async Task<int> GetValueAsync()
{
    return await ComputeValueAsync(); // 不必要的 await
}

// ✅ 高效：直接返回 Task
public Task<int> GetValueAsync()
{
    return ComputeValueAsync();
}

2. ValueTask 优化

// 高频缓存场景：使用 ValueTask 减少内存分配
public async ValueTask<User> GetUserAsync(int id)
{
    // 快速路径：缓存命中，无需分配 Task 对象
    if (_cache.TryGetValue(id, out var user))
        return user;
    
    // 慢速路径：需要异步查询
    user = await _repository.FindByIdAsync(id);
    _cache[id] = user;
    return user;
}

3. 并行处理

// ❌ 串行：慢
var user = await GetUserAsync(id);
var orders = await GetOrdersAsync(id);
var payments = await GetPaymentsAsync(id);

// ✅ 并行：快 3 倍
var userTask = GetUserAsync(id);
var ordersTask = GetOrdersAsync(id);
var paymentsTask = GetPaymentsAsync(id);

await Task.WhenAll(userTask, ordersTask, paymentsTask);

var user = await userTask;
var orders = await ordersTask;
var payments = await paymentsTask;

取消支持

长时间运行的操作应该支持取消：

public async Task<IEnumerable<User>> GetUsersAsync(
    CancellationToken cancellationToken = default)
{
    var users = new List<User>();
    
    await foreach (var user in _repository.StreamUsersAsync(cancellationToken))
    {
        cancellationToken.ThrowIfCancellationRequested();
        users.Add(user);
    }
    
    return users;
}

// 使用示例
var cts = new CancellationTokenSource(TimeSpan.FromSeconds(30));

try
{
    var users = await GetUsersAsync(cts.Token);
}
catch (OperationCanceledException)
{
    Console.WriteLine("操作被取消");
}

实战案例：异步 HTTP 请求

public class HttpClientWrapper
{
    private readonly HttpClient _httpClient;
    private readonly ILogger<HttpClientWrapper> _logger;

    public HttpClientWrapper(
        HttpClient httpClient,
        ILogger<HttpClientWrapper> logger)
    {
        _httpClient = httpClient;
        _logger = logger;
    }

    public async Task<T> GetAsync<T>(
        string url,
        CancellationToken cancellationToken = default)
    {
        try
        {
            var response = await _httpClient
                .GetAsync(url, cancellationToken)
                .ConfigureAwait(false);

            response.EnsureSuccessStatusCode();

            var content = await response
                .Content
                .ReadAsStringAsync(cancellationToken)
                .ConfigureAwait(false);

            return JsonSerializer.Deserialize<T>(content);
        }
        catch (HttpRequestException ex)
        {
            _logger.LogError(ex, "HTTP 请求失败: {Url}", url);
            throw;
        }
        catch (JsonException ex)
        {
            _logger.LogError(ex, "JSON 反序列化失败: {Url}", url);
            throw;
        }
    }
}

总结

C# 异步编程的核心原则：

• 始终使用 await：避免 .Result 或 .Wait() 导致的死锁
• 避免 async void：使用 Task 返回类型以便异常处理
• 优化性能：使用 ConfigureAwait(false)、ValueTask、并行处理
• 支持取消：长时间运行的操作应该接受 CancellationToken
• 正确处理异常：使用 try/catch 捕获异步异常

掌握这些技巧，你就能写出高效、可靠的异步代码，充分发挥 .NET 平台的并发处理能力。

pmset -g

pmset -g

常用设置

关闭显示器（分钟）

sudo pmset displaysleep 15

sudo pmset displaysleep 15

电脑休眠（分钟）

sudo pmset sleep 30

sudo pmset sleep 30

硬盘休眠（分钟）

sudo pmset disksleep 10

sudo pmset disksleep 10

待机延迟（秒）

sudo pmset standbydelay 10800

sudo pmset standbydelay 10800

混合休眠模式

sudo pmset standby 1 # 启用待机
sudo pmset hibernatemode 25 # 混合休眠

sudo pmset standby 1 # 启用待机
sudo pmset hibernatemode 25 # 混合休眠

常用组合

永不休眠（接电源）

sudo pmset -c sleep 0 displaysleep 0 disksleep 0

sudo pmset -c sleep 0 displaysleep 0 disksleep 0

电池省电模式

sudo pmset -b sleep 15 displaysleep 5 disksleep 10

sudo pmset -b sleep 15 displaysleep 5 disksleep 10

字段说明

查看所有设置详情

pmset -g custom

pmset -g custom

恢复默认设置

sudo pmset -a sleep 10 displaysleep 10 disksleep 10

sudo pmset -a sleep 10 displaysleep 10 disksleep 10

禁用休眠（适合常开机）

sudo pmset -a sleep 0 disksleep 0
udo pmset -a hibernatemode 0

sudo pmset -a sleep 0 disksleep 0
udo pmset -a hibernatemode 0

查看唤醒原因

# 查看当前阻止系统 / 显示器睡眠的所有电源断言（Power Assertions），快速定位 Mac 无法自动休眠的原因。
pmset -g assertions 

# 查看唤醒原因
pmset -g | grep wake

# 查看当前阻止系统 / 显示器睡眠的所有电源断言（Power Assertions），快速定位 Mac 无法自动休眠的原因。
pmset -g assertions 

# 查看唤醒原因
pmset -g | grep wake

参数说明

• -a 所有电源模式
• -c 电源适配器（接充电器）
• -b 电池模式
• -u UPS 模式

hibernatemode 取值

• 0 – 内存休眠，唤醒快
• 1 – 安全休眠到磁盘
• 3 – 内存+磁盘混合（默认）
• 25 – 强制休眠到磁盘

相关命令

# 立即锁屏
pmset displaysleepnow

# 查看电池状态
pmset -g batt

# 查看唤醒原因
pmset -g wake

# 立即锁屏
pmset displaysleepnow

# 查看电池状态
pmset -g batt

# 查看唤醒原因
pmset -g wake

来源: macOS 系统命令

在程序化广告生态中，DSP（需求方平台）、ADX（广告交易平台） 与 SSP（供应方平台） 之间的实时通信是整个竞价链路的核心。而这套通信机制的基础，正是 OpenRTB 协议。

本文将从协议结构、关键字段、实际案例三个维度，帮你快速掌握 OpenRTB 的核心要点。

一、为什么需要 OpenRTB？

传统广告投放依赖人工操作，效率低、粒度粗。而程序化广告追求 毫秒级响应、实时竞价、精准定向，必须有一套标准化的数据交换格式。

OpenRTB（Real-Time Bidding）由 IAB（Interactive Advertising Bureau） 主导制定，目前主流版本是 OpenRTB 2.5。

核心价值：

• 统一数据格式，降低对接成本
• 支持实时竞价，毫秒级响应
• 丰富的扩展字段，满足业务定制化需求

二、协议结构一览

一次完整的竞价流程涉及两个核心请求：

1. Bid Request（出价请求）— ADX → DSP

这是 ADX 向 DSP 发送的"竞价邀请"，包含广告位信息、用户特征、投放限制等。

{
  "id": "abc123-uuid",
  "tmax": 120,
  "device": {
    "ua": "Mozilla/5.0...",
    "ip": "203.0.113.42",
    "geo": {
      "country": "CHN",
      "city": "Dalian"
    }
  },
  "user": {
    "id": "user_xyz789",
    "data": [{
      "segment": [{"id": "interest_tech"}]
    }]
  },
  "imp": [{
    "id": "1",
    "bidfloor": 0.5,
    "banner": {
      "w": 300,
      "h": 250,
      "mimes": ["image/jpeg", "image/png"]
    }
  }],
  "site": {
    "id": "site_001",
    "name": "News Portal",
    "publisher": {"id": "pub_123"}
  }
}

关键字段解读：

• <code>id</code>: 唯一请求标识，用于关联后续响应
• <code>tmax</code>: 超时时间（毫秒），DSP 必须在此时限内返回响应
• <code>device</code>: 设备信息（UA、IP、地理位置），用于用户定向
• <code>imp</code>: 广告展示请求列表，每个 <code>imp</code> 代表一个广告位
• <code>bidfloor</code>: 最低出价（CPM）

2. Bid Response（出价响应）— DSP → ADX

DSP 收到请求后，经过竞价决策，返回出价结果。

{
  "id": "abc123-uuid",
  "seatbid": [{
    "bid": [{
      "id": "bid_001",
      "impid": "1",
      "price": 1.25,
      "adm": "<html><img src=https://ad.example.com/creative.jpg/></html>",
      "crid": "creative_888",
      "nurl": "https://dsp.example.com/win?price=${AUCTION_PRICE}"
    }]
  }],
  "bidid": "bid_response_001"
}

关键字段解读：

• <code>seatbid</code>: 出价席位列表
• <code>price</code>: 出价金额（CPM）
• <code>adm</code>: 广告物料（HTML、图片、VAST 等）
• <code>crid</code>: 创意 ID，用于素材追踪
• <code>nurl</code>: 竞价获胜通知地址，<code>${AUCTION_PRICE}</code> 会被替换为实际成交价

三、实战：竞价超时处理

在 RTB 项目中，超时控制是性能优化的关键。

根据行业实践和 MEMORY.md 中记录的约束要求：

• Bid Request 处理 < 30ms
• Redis 读写 < 5ms

超时处理代码示例（C#）：

public async Task<BidResponse> HandleBidRequestAsync(BidRequest request, CancellationToken ct)
{
    // 创建超时任务
    var timeoutTask = Task.Delay(25, ct); // 预留 5ms 余量

    // 并行执行竞价逻辑
    var biddingTask = ExecuteBiddingAsync(request, ct);

    // 任一任务完成即返回
    var completedTask = await Task.WhenAny(biddingTask, timeoutTask);

    if (completedTask == timeoutTask)
    {
        // 超时，返回默认响应或空响应
        _logger.LogWarning("Bid request {RequestId} timed out", request.Id);
        return CreateDefaultResponse(request.Id);
    }

    return await biddingTask;
}

Redis 缓存优化策略：

public async Task<UserProfile> GetUserProfileAsync(string userId)
{
    var cacheKey = $"user:{userId}";

    // 先查 Redis（目标 < 5ms）
    var cached = await _redisDatabase.StringGetAsync(cacheKey);
    if (cached.HasValue)
    {
        return JsonSerializer.Deserialize<UserProfile>(cached);
    }

    // 缓存未命中，查 DB 后回填
    var profile = await _repository.GetUserProfileAsync(userId);

    // 异步回写缓存
    _ = _redisDatabase.StringSetAsync(cacheKey, 
        JsonSerializer.Serialize(profile), 
        TimeSpan.FromMinutes(5));

    return profile;
}

四、注意事项

1. 协议版本兼容性：不同 ADX 可能使用不同版本的 OpenRTB，需做好版本适配层
2. 安全传输：生产环境必须使用 HTTPS/TLS，防止请求被篡改
3. 日志脱敏：用户 IP、设备 ID 等敏感信息在日志中需脱敏处理
4. 幂等性：ID 生成和请求处理需保证幂等，避免重复计费

五、总结

OpenRTB 是程序化广告的"通用语言"，掌握其协议结构和实战用法，是开发 DSP/ADX 系统的基础。建议结合实际项目（如 Google Authorized Buyers、OpenRTB 规范文档）深入学习。

参考来源：

• IAB OpenRTB 2.5 Specification
• Google Authorized Buyers API Documentation

关注我，获取更多 RTB 实战经验与 .NET 性能优化技巧。

对于 .NET Framework 4.5.2 项目，在 macOS 上需要使用 Mono 来运行。

第一步：安装必需工具

1. 安装 Mono

brew install mono

验证安装：

mono --version

2. 安装 NuGet

brew install nuget

3. 安装 MSBuild (包含在 Mono 中)

验证安装：

msbuild -version

4. 安装 XSP (Mono 的 Web 服务器)

brew install xsp

第二步：安装 VSCode 扩展

在 VSCode 中安装以下扩展（已在 <code>.vscode/extensions.json</code> 中推荐）：

1. C# Dev Kit – 微软官方 C# 支持
2. C# – OmniSharp 语言服务
3. .NET Test Explorer – 测试资源管理器

重启 VSCode 以激活扩展。

第三步：构建项目

方法 1：使用 VSCode 任务（推荐）

1. 按 <code>Cmd+Shift+P</code> 打开命令面板
2. 选择 <code>Tasks: Run Task</code>
3. 选择 <code>构建解决方案 (Debug)</code>

方法 2：使用终端命令

# 恢复 NuGet 包
nuget restore <Solution-Name>.sln

# 构建项目
msbuild <Solution-Name>.sln /p:Configuration=Debug

第四步：运行和调试

运行 WebAPI 项目

方法 1：使用 XSP（Mono Web 服务器）

# 在终端中运行
xsp4 --port=<PORT> --path=<ProjectName>

然后访问：http://localhost:23985/api/message

方法 2：使用 VSCode 任务

1. 按 <code>Cmd+Shift+P</code>
2. 选择 <code>Tasks: Run Task</code>
3. 选择 <code>运行 WebAPI (XSP)</code>

调试代码

1. 在代码中设置断点（点击行号左侧）
2. 按 <code>F5</code> 或点击调试面板的"开始调试"
3. 选择配置：<code>调试 WebAPI (Mono)</code>

运行单元测试

使用 VSCode 任务：

1. 按 <code>Cmd+Shift+P</code>
2. 选择 <code>Tasks: Run Task</code>
3. 选择 <code>运行单元测试</code>

使用命令行：

# 首先需要安装 NUnit Console Runner（如果还没有）
nuget install NUnit.ConsoleRunner -Version 3.15.0 -OutputDirectory packages

# 运行测试
mono packages/NUnit.ConsoleRunner.3.15.0/tools/nunit3-console.exe \
  <TestProjectName>/bin/Debug/<TestProjectName>.dll

常用 VSCode 快捷键

• <code>Cmd+Shift+B</code> – 运行默认构建任务
• <code>F5</code> – 开始调试
• <code>Shift+F5</code> – 停止调试
• <code>F9</code> – 切换断点
• <code>F10</code> – 单步跳过
• <code>F11</code> – 单步进入
• <code>Cmd+K Cmd+D</code> – 格式化文档

常见问题

1. Mono 找不到程序集

确保已运行 <code>nuget restore</code> 来恢复所有依赖包。

2. MSBuild 失败

检查 Mono 版本是否支持 .NET Framework 4.5.2：

mono --version

需要 Mono 5.0 或更高版本。

3. XSP 无法启动

确保端口 23985 未被占用：

lsof -i :23985

4. OmniSharp 无法加载项目

在 VSCode 设置中确保：

• <code>omnisharp.useModernNet</code> 设置为 <code>false</code>
• <code>omnisharp.monoPath</code> 指向正确的 Mono 安装路径

已知限制

1. 调试功能受限：Mono 的调试体验不如 Windows 上的 Visual Studio
2. 性能差异：Mono 运行性能可能低于 Windows .NET Framework
3. 某些 API 不可用：部分 Windows 特定的 API 在 Mono 上不支持

建议

对于生产环境部署，建议：

1. 在 Windows Server 上使用 IIS 托管
2. 或考虑将项目迁移到 .NET 6/8 以获得跨平台支持

迁移到现代 .NET 的好处

如果你计划长期维护此项目，可以考虑迁移到 .NET 8：

• 原生跨平台支持（无需 Mono）
• 更好的性能
• 现代化的工具链
• 长期支持（LTS）

迁移步骤请参考：https://docs.microsoft.com/zh-cn/aspnet/core/migration/

本地运行后端项目后，通过浏览器调用 API 时提示：

 POST https://<ip>:<port>/path net::ERR_CERT_AUTHORITY_INVALID

原因：本地开发环境使用的是 .NET 自签名 HTTPS 证书，浏览器默认不信任该证书。

解决方案

方案 1：信任 .NET 开发证书（推荐）

 dotnet dev-certs https --trust

如果提示证书已存在但不信任，先清理再重新生成：

 dotnet dev-certs https --clean
 dotnet dev-certs https --trust

一次性解决，之后所有 .NET 本地开发项目都会自动信任。

方案 2：使用 HTTP 端口

修改前端 SDK 的开发环境端点，使用 HTTP 端口 <code>5085</code> 而非 HTTPS 端口 <code>7218</code>：

 // webpack.config.js 或 sdk.js 中
 resolveEndpoint: 'http://<ip>:<port>/path'

方案 3：浏览器手动信任

1. 直接访问 <code>https://<ip>:<port>/swagger</code>
2. 浏览器会提示"不安全"，点击"高级" → "继续访问"

3. 之后该证书在当前浏览器会话中被临时信任

   方案 4：Chrome 启动参数（临时）

   # macOS
   open -a "Google Chrome" --args --ignore-certificate-errors --ignore-urlfetcher-cert-requests
   
   # Windows
   chrome.exe --ignore-certificate-errors --ignore-urlfetcher-cert-requests

   注意：此方式会忽略所有证书错误，仅用于开发调试。

添加 Microsoft 仓库

sudo rpm -Uvh https://packages.microsoft.com/config/centos/8/packages-microsoft-prod.rpm

安装运行时

sudo dnf install -y aspnetcore-runtime-8.0

验证

dotnet –list-runtimes

如果上面的源不可用，可以用脚本安装：

下载安装脚本

curl -sSL https://dot.net/v1/dotnet-install.sh -o dotnet-install.sh
chmod +x dotnet-install.sh

安装到 /usr/share/dotnet（全局）

sudo ./dotnet-install.sh –channel 8.0 –runtime aspnetcore –install-dir /usr/share/dotnet

创建软链接

sudo ln -sf /usr/share/dotnet/dotnet /usr/bin/dotnet

验证

dotnet –list-runtimes

本文是一次完整的 线上问题排查 + 架构修复 + 压力测试验证 的工程级总结，可作为 事故复盘、容量评估报告、运维 Runbook 使用。

一、问题背景与现象

初始问题

• Nginx 错误日志频繁出现：

  upstream timed out (110: Connection timed out) while connecting to upstream

• 请求多为：

  OPTIONS /api/Ads/resolve HTTP/2.0

• 上游地址：<code>127.0.0.1:5085</code>（.NET Kestrel）

同时观测到的内核异常

• <code>listen queue overflow</code>
• <code>SYNs to LISTEN sockets dropped</code>
• <code>SYN cookies sent</code>
• <code>TCPTimeWaitOverflow</code>

直接影响

• Nginx 无法连接本机上游
• API 出现大量失败
• 高并发下服务不可用

二、根因分析（结论级）

1⃣ Nginx → Kestrel 连接模型错误（核心根因）

在 <code>location /</code> 中错误地配置了：

proxy_set_header Connection "upgrade";

导致：

• 所有普通 HTTP 请求被迫使用 <code>Connection: upgrade</code>
• Keepalive 失效
• 每个请求都建立/断开 TCP 连接

直接引发短连接风暴

2⃣ OPTIONS 预检请求被放大

• 外站（如豆瓣）触发大量跨域请求
• 每个请求都会先发 <code>OPTIONS</code>
• <code>OPTIONS</code> 被转发到上游应用

在短连接模型下形成 连接洪峰。

3⃣ 内核层连锁反应

• SYN backlog 被打满
• accept queue 溢出
• 内核开始丢 SYN / 启用 SYN cookies
• Nginx 连接上游直接超时（110）

三、关键修复措施（工程级）

1⃣ 引入 upstream keepalive（最关键修复）

在 <code>http {}</code> 作用域中新增：

upstream eaglex_upstream {
    server 127.0.0.1:5085;
    keepalive 256;
}

统一使用：

proxy_pass http://eaglex_upstream;
proxy_http_version 1.1;
proxy_set_header Connection "";

2⃣ 修正 Connection 头使用方式（非常关键）

• 禁止在普通 HTTP 路径中使用：

  Connection: upgrade

• 只在 WebSocket 专用 location 中使用 upgrade

3⃣ 在 Nginx 层直接短路 OPTIONS 预检

location = /api/Ads/resolve {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin $http_origin always;
        add_header Access-Control-Allow-Methods "GET,POST,OPTIONS" always;
        add_header Access-Control-Allow-Headers "Content-Type,Authorization" always;
        add_header Access-Control-Max-Age 86400 always;
        return 204;
    }
    proxy_pass http://eaglex_upstream;
}

彻底消除预检请求对上游的压力放大

4⃣ 缩短 proxy_connect_timeout（防止雪崩）

proxy_connect_timeout 2s;

避免 Nginx worker 在连接失败时长时间阻塞。

四、压测阶段的验证结论

压测过程中观测到的健康状态

• <code>.NET</code> CPU：≈ 260%–300%（4C 机器，尚有余量）
• Nginx CPU：≈ 10%–20%
• <code>ksoftirqd</code>：极低

• TCP 状态：

  estab ≈ 3000
  timewait ≈ 30
  orphan = 0

• 内核累计计数在压测前后 完全无增长：

  • listen queue overflow
  • SYN dropped
  • TCPTimeWaitOverflow

明确结论

连接层 / Nginx / 内核 TCP 已完全稳定，系统瓶颈成功转移至 .NET 应用 CPU 层。

五、错误日志的两类问题区分（重要）

A. <code>110 Connection timed out</code>

while connecting to upstream

• 含义：连接队列 / accept / backlog 问题
• 根因：连接模型错误
• 已在本次修复中解决

B. <code>111 Connection refused</code>

connect() failed (111: Connection refused)

• 含义：上游端口当时 没有进程在监听

• 可能原因：

  • dotnet 进程崩溃
  • 被 OOM killer 杀死
  • 重启 / 发布

属于 上游进程稳定性问题，与 backlog 无关。

六、压测与日常排障常用监控命令清单

1⃣ TCP 全局状态（必看）

ss -s

关注：<code>estab / timewait / orphan</code>

2⃣ 上游端口连接数（Nginx → Kestrel）

ss -ant | awk '$4=="127.0.0.1:5085"{c++} END{print c}'

3⃣ 上游连接状态分布

ss -ant | awk '$4=="127.0.0.1:5085"{print $1}' | sort | uniq -c | sort -nr

4⃣ 内核是否再次被打爆（差分判断）

netstat -s | egrep -i 'listen queue|SYNs to LISTEN|SYN cookies|TCPTimeWaitOverflow'

必须用 前后对比 判断是否仍在发生。

5⃣ Nginx 错误日志关键字

tail -n 200 /www/wwwlogs/eaglex_ads_api.error.log | egrep -i 'timed out|refused|502|504'

6⃣ 上游进程是否存活 / 是否重启

ps -p <dotnet_pid> -o pid,etimes,%cpu,%mem,cmd
ss -lntp | grep 5085

7⃣ OOM / 内核杀进程检查

dmesg -T | egrep -i 'oom|killed process'
journalctl -k | egrep -i 'oom|killed'

8⃣ .NET 运行时指标（强烈推荐）

dotnet-counters monitor System.Runtime --process-id <pid>

关注：

• CPU Usage
• ThreadPool Queue Length
• % Time in GC

七、最终工程级结论（可直接写入文档）

本次问题的根因是 Nginx → Kestrel 连接模型错误（短连接 + OPTIONS 预检放大），导致 TCP listen queue 溢出与 upstream connect timeout。

通过引入 upstream keepalive、修正 Connection 头、在 Nginx 层短路 CORS 预检，并配合合理的超时配置，连接层问题已完全消除。

压测结果表明：系统当前瓶颈已转移至 .NET 应用 CPU 层，TCP 与代理层稳定可靠，具备可预测的容量上限。

问题场景

• 不小心提交了 API 密钥、密码
• 配置文件中包含真实域名或个人信息
• 已推送到 GitHub 等公开仓库

解决方案’"

方法一：使用 git filter-branch（内置工具）

适用于替换历史中所有提交的某个文件内容。

# 1. 暂存当前未提交的更改
git stash'"

# 2. 替换历史中所有 README.md 文件里的敏感内容
FILTER_BRANCH_SQUELCH_WARNING=1 git filter-branch --force --tree-filter \
  "find . -name 'README.md' -exec sed -i '' 's/敏感内容/替换内容/g' {} \;" \
  -- --all

# 3. 恢复暂存的更改
git stash pop

# 4. 强制推送到远程仓库（覆盖历史）
git push origin main --force

参数说明

方法二：使用 BFG Repo-Cleaner（推荐，更快）

适用于删除大文件或敏感文件。

# 安装 BFG
brew install bfg

# 删除某个文件的所有历史
bfg --delete-files 敏感文件.txt

# 或替换敏感文本
bfg --replace-text passwords.txt

# 清理并强制推送
git reflog expire --expire=now --all
git gc --prune=now --aggressive
git push origin main --force

方法三：使用 git filter-repo（官方推荐）

# 安装
brew install git-filter-repo

# 替换敏感内容
git filter-repo --replace-text <(echo '敏感内容==>替换内容')

# 重新添加远程并推送
git remote add origin https://github.com/user/repo.git
git push origin main --force

注意事项

1. 强制推送有风险：会覆盖远程历史，协作者需要重新克隆仓库
2. 轮换密钥：敏感信息一旦泄露，应立即轮换（如重新生成 API Key）
3. GitHub 缓存：GitHub 可能会缓存提交，联系 GitHub 支持可请求清除
4. 本地备份：操作前建议备份仓库 <code>cp -r .git .git.backup</code>

预防措施

• 使用 <code>.gitignore</code> 忽略敏感文件
• 使用环境变量存储敏感配置
• 提交前检查 <code>git diff –staged</code>
• 启用 GitHub 的 Secret Scanning 功能

总结

1. git stash – 暂存当前未提交的更改
2. git filter-branch –tree-filter – 遍历所有历史提交，用 sed 替换敏感内容
3. git stash pop – 恢复暂存的更改
4. git push –force – 强制推送覆盖远程历史

一行通用万能命令（推荐直接用这个）

在 终端（Terminal） 中执行：

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

输入你的 系统登录密码（不会显示），回车即可完成刷新。

这个命令适用于：

• macOS Ventura (13)
• macOS Sonoma (14)
• macOS Sequoia (15)
• Monterey (12)
• Big Sur (11)
• Catalina (10.15)
• Mojave (10.14)

各系统版本对应命令（备用参考）

如何判断是否刷新成功？

macOS 刷新 DNS 默认是没有任何成功提示的，这是正常现象
如果你想确认是否真的生效，可以：

ping your-domain.com

或：

nslookup your-domain.com

适合你的使用场景（比如你刚刚在折腾这些）

你最近使用的场景包括：

• 花生壳 / 动态域名解析
• 公网 IP + 远程桌面
• 路由器 DDNS 解析切换
• 域名刚刚改解析但访问不生效

这时候刷新 DNS 是“必须操作”之一，否则很容易一直命中旧 IP。

进阶：同时刷新 WiFi/网络缓存（更彻底）

如果你遇到的是那种 “DNS 已改，但 Mac 仍然连不上” 的顽固情况，可以：

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
sudo ifconfig en0 down
sudo ifconfig en0 up

（<code>en0</code> 是常见的 WiFi 网卡）