v4.4.2026.0310

Author: nnhy

.github/instructions/benchmark.instructions.md

@@ -74,79 +74,4 @@ public Int32 ThreadCount { get; set; }
 4. **对比分析**
    - 纵向：同场景不同并发趋势，找出最优并发点
    - 横向：不同方案同并发差异百分比
-5. 性能瓶颈定位（按重要程度排序）→ 优化建议（含预期收益与内存节省预估）
-
-## 8. 性能瓶颈定位规范
-
-性能瓶颈定位章节是报告的核心价值输出，必须遵循以下规范：
-
-### 8.1 瓶颈点结构（每个瓶颈必须包含）
-
-每个瓶颈点必须包含以下要素，缺一不可：
-
-| 要素 | 说明 | 示例 |
-|------|------|------|
-| **优先级标签** | P0/P1/P2/P3，按影响程度降序 | P0 |
-| **瓶颈名称** | 一句话准确描述瓶颈 | VisitTime 写入触发 MESI 缓存行争用 |
-| **优化收益占比** | 该瓶颈在总体可优化空间中的占比 | ~35% |
-| **现象与数据** | 用 BDN 实测数据量化问题严重程度 | 4T→8T 扩展仅 1.3x，低于预期 2.0x |
-| **根因分析** | 从代码执行路径分析到底层硬件行为 | Get 每次写 VisitTime → 缓存行 Modified → 多核 MESI 失效 |
-| **开销占比估算** | 在单次操作总耗时中的占比 | 占 Get 总耗时 30%~40% |
-| **内存影响** | 每次操作的额外内存分配或 GC 压力 | 48 B/次装箱分配，32 线程累计 3 MB |
-| **优化方向** | 具体可落地的优化方案 | 时间窗口内跳过更新（如 1s 内不重复写） |
-| **预期收益** | 速度提升倍数 + 内存节省比例 | 多线程吞吐 +20-30%，消除缓存行争用 |
-
-### 8.2 瓶颈分级标准
-
-| 级别 | 定义 | 优化收益占比 | 行动 |
-|------|------|------------|------|
-| **P0** | 影响核心吞吐或造成 >30% 性能损失 | ≥25% | 必须优化 |
-| **P1** | 影响多线程扩展性或造成显著内存压力 | 15%~25% | 建议优化 |
-| **P2** | 特定场景下的次要瓶颈 | 5%~15% | 可选优化 |
-| **P3** | 微小开销，仅在极端场景有影响 | <5% | 记录备查 |
-
-### 8.3 瓶颈定位表格模板
-
-性能瓶颈定位章节使用以下统一表格格式：
-
-```markdown
-### 核心瓶颈点总览
-
-| 优先级 | 瓶颈 | 优化收益占比 | 当前开销 | 优化后预估 | 内存节省 |
-|--------|------|------------|---------|-----------|---------|
-| P0 | {瓶颈名称} | ~{X}% | {耗时/分配} | {目标值} | {节省比例} |
-| P1 | {瓶颈名称} | ~{X}% | {耗时/分配} | {目标值} | {节省比例} |
-| ... | ... | ... | ... | ... | ... |
-```
-
-### 8.4 内存优化方向表格模板
-
-紧跟瓶颈总览表之后，补充内存优化方向：
-
-```markdown
-### 关键内存优化方向
-
-| 优先级 | 优化方向 | 当前分配 | 优化后预估 | 节省比例 | 实施方案 |
-|--------|---------|---------|-----------|---------|---------|
-| P0 | {方向} | {X} B/op | {Y} B/op | {Z}% | {方案} |
-| ... | ... | ... | ... | ... | ... |
-```
-
-### 8.5 开销拆解要求
-
-对每个核心操作，必须给出开销来源拆解表：
-
-```markdown
-| 开销来源 | 占比估算 | 耗时估算 | 说明 |
-|---------|---------|---------|------|
-| {来源1} | ~{X}% | ~{N} ns | {原因} |
-| {来源2} | ~{X}% | ~{N} ns | {原因} |
-```
-
-### 8.6 撰写原则
-
-- **数据驱动**：所有结论必须有 BDN 实测数据支撑，禁止无数据臆测
-- **量化优先**：用"快 X 倍"、"省 Y%"、"降 Z B/op"表达，避免"显著"、"明显"等模糊词
-- **根因到底**：从应用层代码 → 运行时机制 → CPU 微架构逐层分析
-- **可操作**：每个优化建议必须指明具体修改位置和实施方案，而非泛泛建议
-- **排序严格**：P0 在前，P3 在后，同级按收益占比降序
+5. 性能瓶颈定位 → 优化建议（按优先级排序，含预期收益）

AntJob.Web/AntJob.Web.csproj

@@ -1,7 +1,7 @@
 <Project Sdk="Microsoft.NET.Sdk.Web">
   <PropertyGroup>
     <AssemblyName>AntWeb</AssemblyName>
-    <TargetFramework>net10.0</TargetFramework>
+    <TargetFrameworks>net8.0;net10.0</TargetFrameworks>
     <AssemblyTitle>蚂蚁调度管理</AssemblyTitle>
     <Description>AntJob 可视化管理平台，提供任务调度、监控、日志查询和集群管理功能。</Description>
     <Company>新生命开发团队</Company>

AntJob/AntJob.csproj

@@ -49,7 +49,7 @@
   </ItemGroup>
 
   <ItemGroup>
-    <PackageReference Include="NewLife.Core" Version="11.13.2026.308" />
+    <PackageReference Include="NewLife.Core" Version="11.13.2026.301" />
     <PackageReference Include="NewLife.Remoting" Version="3.7.2026.302" />
     <PackageReference Include="NewLife.Stardust" Version="3.7.2026.307" />
   </ItemGroup>