个人整理,仅供参考。具体规格请以官方发布为准。
表格于 2025 年 11 月整理更新。
使用 Linq 语法调用数据库时,需要包含导航属性(外键表数据)会用到 Include 方法,但是如果引用的程序集搞错了,就不会有数据输出,应该:
using Microsoft.EntityFrameworkCore;
而不是
using System.Data.Entity;
个人整理,仅供参考。具体规格请以官方发布为准。
![]() | ![]() | ![]() | ![]() | ![]() | ![]() | ![]() | |
|---|---|---|---|---|---|---|---|
| 名称 | 万兆路由器BE10000 | BE7000 | BE6500 Pro | BE6500 | 全屋 BE3600 Pro 套装 | 全屋 BE3600 Pro 网线版 | BE10000 Pro |
| 型号 | 主:RN04 子:RN01 | 主:RP01 子:RP03 | |||||
| 上市时间 | 2022.10 | 2023.5 | 2023.10 | 2024.8 | 2024.10 | 2025.5 | 2025.9 |
| 处理器 | Qualcomm 四核 A73 2.2GHz | Qualcomm 四核 A73 1.5GHz | Qualcomm 四核 A53 1.5GHz | Qualcomm 四核 A53 1.1GHz | 主/子: 高通 IPQ5312 四核 1.1GHz | 主/子: Qualcomm Dragonwing N7 | Qualcomm A7 四核 1.8GHz |
| 内存 | 2GB | 1GB | 1GB | 512MB | 主/子:512MB 一说子是 128MB | 主:512MB 子:256MB | 2GB |
| 频段 | 2.4GHz、5.2GHz、5.8GHz | 2.4GHz、5GHz | 2.4GHz、5GHz | 2.4GHz、5GHz | 2.4GHz、5GHz | 2.4GHz、5GHz | 2.4GHz、5.2GHz、5.8GHz |
| 组网 | 混合 Mesh | 混合 Mesh | 混合 Mesh | 混合 Mesh | 混合 Mesh | AC + AP | AI Mesh |
| 天线 | 12根高增益天线 + 12路信号放大器 + NFC内置天线 | 7根外置高增益WiFi天线 + 1根内置高增益WiFi天线 + NFC内置天线 | 6根高增益WiFi内置天线 + 1根蓝牙内置天线 + 1根NFC内置天线 | 6根外置高增益Wi-Fi天线 | 主/子:4根内置天线 | 主:无 子:2根内置双频天线 | 12根高增益天线 + 12路信号放大器 |
| 中枢网关 | 不支持 | 不支持 | 支持 | 不支持 | 主:支持 子:不支持 | 主:支持 子:不支持 | 支持 |
| 蓝牙网关 | 不支持 | 不支持 | 蓝牙 Mesh 1.0 100 台 + 蓝牙 100 台 升级固件后支持蓝牙 Mesh 2.0 | 蓝牙 Mesh 1.0 | 蓝牙 Mesh 1.0 200 台 + 蓝牙 100 台 | 主:不支持 子:蓝牙 Mesh 2.0 | 蓝牙 Mesh 2.0 200 台 + 蓝牙 100 台 |
| 散热 | 主动散热 | 自然散热 | 自然散热 | 自然散热 | 自然散热 | 主:自然散热 子:主动散热 | 主动散热 |
| 接口 | 4×2.5G 1×10G 1×10G SFP+ 1×USB 3.0 | 4×2.5G 1×USB 3.0 | 4×2.5G | 4×2.5G | 主/子: 1×2.5G 3×1G | 主:5×2.5G 子:2×2.5G | 4×2.5G 2×10G 1×M.2 1×USB 3.0 |
| Wi-Fi | Wi-Fi 7 | Wi-Fi 7 | Wi-Fi 7 | Wi-Fi 7 | Wi-Fi 7 | 主:无 子:Wi-Fi 7 | Wi-Fi 7 |
| 价格 | 最新价格 | 最新价格 | 最新价格 | 最新价格 | 最新价格 | 最新价格 | 最新价格 |
表格于 2025 年 10 月整理更新。
如果只考虑支持蓝牙 Mesh 2.0,那么有 BE3600 Pro 网线版 和 BE10000 Pro 可选,搭配其它 Mesh 路由器实现全屋 Wi-Fi 7 覆盖,搭配其它中枢网关或从网关设备实现全屋蓝牙 Mesh 2.0 覆盖。
如果考虑用 Xiaomi 中枢网关 来部署独立的中枢架构,那么选择路由器就没有限制了。
名称中带有“全屋”字样的通常以子母套装形式出售,子母路由配置通常不同。购买两台一模一样的普通 BE 路由器,就相当于组建了一套“不分子母”的 Mesh 套装。
名称中带有“Pro”字样的通常具备中枢网关功能。
在 Linux 上运行 .NET 网站,通过
HttpContext.Connection.RemoteIpAddress获取客户端的 IP 地址,结果是
::ffff:127.0.0.1解决方法:
打开 Program.cs 文件,在 var app = builder.Build(); 之前(尽量往前)添加以下代码:
if (OperatingSystem.IsLinux())
{
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders = ForwardedHeaders.XForwardedFor
| ForwardedHeaders.XForwardedProto
| ForwardedHeaders.XForwardedHost;
// 清除 KnownNetworks 和 KnownProxies,表示信任来自本机的代理(如 Nginx)
options.KnownNetworks.Clear();
options.KnownProxies.Clear();
});
Console.WriteLine("ForwardedHeaders enabled (Running on Linux)");
}然后在 app.UseRouting(); 之前添加以下代码:
if (OperatingSystem.IsLinux())
{
app.UseForwardedHeaders();
Console.WriteLine("UseForwardedHeaders() applied.");
}其中,OperatingSystem.IsLinux() 用于判断只在 Linux 环境中生效,你可以视自身情况作判断。
一、安装 Ollama
从官网下载安装 Ollama。
查看版本号:
ollama --version二、在 shell 中安装和运行模型
在 Models 中选择一个你想部署的模型,复制安装命令,并在终端中执行。
官方建议:应该至少有 8 GB 的 RAM 来运行 7b 版本,16 GB 的 RAM 来运行 13b 版本,32 GB 的 RAM 来运行 33b 版本。
本文以 deepseek-r1:7b 为例。
下载模型
ollama pull deepseek-r1:7bTip: 下载即将完成时速度可能会变得非常慢,只要按 Ctrl+C,再重新执行一次命令,就会继续正常下载。
显示模型信息
ollama show deepseek-r1:7b运行模型(一次性响应)
ollama run deepseek-r1:7b "写一首诗"运行模型(进入聊天模式)
ollama run deepseek-r1:7b结束当前会话
/bye列出所有模型
ollama list列出当前加载的模型
ollama ps停止当前正在运行的模型
ollama stop deepseek-r1:7b三、使用 REST API 调用模型
修改端口
ollama serve --port 11434/api/generate 接口:生成一次性响应
curl http://localhost:11434/api/generate -d '{
"model": "deepseek-r1:7b",
"prompt":"为什么天空是蓝色的?"
}'/api/chat 接口:与模型聊天
curl http://localhost:11434/api/chat -d '{
"model": "deepseek-r1:7b",
"messages": [
{ "role": "user", "content": "你好呀!" }
]
}'四、在 .NET 中调用
1、直接 HTTP 调用(基础方案)
创建 HttpClient,使用 PostAsJsonAsync 请求,使用 ReadFromJsonAsync 读取结果。
2、使用 OllamaSharp 库(推荐方案)
创建 OllamaApiClient,使用 SelectedModel 设置模型,使用 GenerateAsync 获得结果。或创建对话 ollama.Chat(),并 Send 内容。
3、.NET Aspire 集成(企业级方案)
适合微服务架构,结合容器化部署。
“OllamaSharp 库”和“.NET Aspire 集成”两种方案怎么选?
OllamaSharp 库:定位轻量级模型交互 SDK,适用于独立应用、微服务中的 AI 组件等场景,技术复度低,支持模型对话/生成/管理、流式响应、多模态支持,需自行实现监控、熔断。
.NET Aspire 集成:定位企业级云原生 AI 服务编排框架,适用于多服务协同的分布式系统,技术复度高,支持服务编排、健康检查、弹性伸缩、混合云部署,内置可观测性仪表盘、自动故障转移。
决策建议:初创项目用 OllamaSharp 快速试错,用户量破千后通过 Aspire 重构。两者并非互斥,可在 Aspire 中封装 OllamaSharp 客户端,兼顾灵活性与运维能力。
IIS 中使用 HttpPlatformHandler 模块部署 python web 项目时遇到 502.3 网关错误:
HTTP 错误 502.3 - Bad Gateway
There was a connection error while trying to route the request.
最可能的原因:
CGI 应用程序没有返回一组有效的 HTTP 错误。
由于父网关中出现错误,充当代理或网关的服务器无法处理该请求。
可尝试的操作:
使用 DebugDiag 排查 CGI 应用程序。
确定此错误是否由代理或网关引起。
详细错误信息:
模块 httpPlatformHandler
通知 ExecuteRequestHandler
处理程序 httpplatformhandler
错误代码 见下方表格
详细信息:
当 CGI 应用程序未返回一组有效的 HTTP 头,或者代理或网关无法将请求发送至父网关时,便会出现此错误。您可能需要获取一个网络跟踪,或者与代理服务器管理员联系(如果不是 CGI 的问题)。
| 错误代码 | 可能的错误原因 |
|---|---|
| 0x8007053d | 未安装相关组件库,建议执行命令:pip install -r requirements.txt |
| 0x80070005 | 若显示配置错误“由于权限不足而无法读取配置文件”则是应用代码目录未配置相应用户的读取权限; 访问受限,请正确配置 IIS 中的网站凭据、应用程序池标识、项目目录“读取”、解释器目录“读取和执行”权限等 |
| 0x80072ee2 | 执行超时,一般发生在批量读写的时候 |
| 0x8007042b | |
| 任何错误 | 查看日志文件。 可能的错误原因:
|
安装“腾讯手机管家”或其它支持按关键词设置黑名单的垃圾信息过滤工具
打开手机设置 - App - 信息 - 未知与过滤信息 - 选择“腾讯手机管家”
打开“腾讯手机管家”- 垃圾短信过滤 - 自定义短信拦截 - 黑名单 - 添加关键词
(每次添加一个词就确定,如果填写多个表示同一条短信中同时包含这些关键词)
在代码中添加“不跟踪”(No-Tracking)功能,以提高查询性能(避免实体状态跟踪)。
确保后续操作无需更新返回的实体(如没有 SaveChanges 操作)。
在条件(Where)、排序(OrderBy、OrderByDescending)、分页(Skip、Take)等之前添加 .AsNoTracking(),如:db.Table.AsNoTracking().Where(...).ToList()。
如果查询中包含导航属性,它们也会因主查询的不跟踪而保持不跟踪状态。
AsNoTracking() 适用于查询简单无嵌套关系,若查询包含 Include/ThenInclude,建议用 AsNoTrackingWithIdentityResolution() 代替,后者更适合处理树形结构或循环引用数据。
添加(Add/AddRange)、修改、删除(Remove/RemoveRange)等有 SaveChanges 操作的场景不能加 .AsNoTracking()。
查询时是否需要加 .AsNoTracking() 参考下表:
数据查询操作体系
├── 限定符 (Any, All) ✔️ 推荐
├── 聚合函数 (Count, Sum, Min, Max, Average) ❌ 不需要(但在分页逻辑中 Count 与 ToList 使用共同条件筛选时建议加)
├── 集合操作 (Distinct, Union) ⚠️ 推荐用于只读
├── 元素操作 (First, Single) ⚠️ 推荐用于只读
└── 即时执行操作 (ToList, ToArray, ToDictionary) ⚠️ 推荐用于只读
临界区与 lock 关键字
核心作用:
通过将多线程访问串行化,保护共享资源或代码段。lock 关键字是 Monitor 类的语法糖,提供异常安全的临界区实现。
实现示例:
// 创建私有静态只读对象 // private static readonly object _lockObj = new object(); private static readonly System.Threading.Lock _locker = new(); // .NET 9+ 推荐使用 Lock 类型,避免传统 object 的性能损耗 public void ThreadSafeMethod() { lock (_lockObj) { // 临界区代码(每次仅一个线程可进入) } }超时机制:
高并发场景可结合 Monitor.TryEnter 设置超时,避免无限等待:
if (Monitor.TryEnter(lockObject, TimeSpan.FromSeconds(1))) { try { /* 操作 */ } finally { Monitor.Exit(lockObject); } }关键特性:
用户态锁(无内核切换开销)
自动调用Monitor.Enter和Monitor.Exit
必须使用专用私有对象作为锁标识
注意事项:
❌ 避免锁定this、Type实例或字符串(易引发死锁)
❌ 避免嵌套锁(需严格按顺序释放)
✅ 推荐readonly修饰锁对象
❌ lock 不适用于异步代码(async/await),需使用 SemaphoreSlim 实现异步锁
互斥锁(Mutex)
核心作用:
系统级内核锁,支持跨进程同步,但性能开销较高(用户态/内核态切换)。
实现示例:
using var mutex = new Mutex(false, "Global\\MyAppMutex"); try { // 等待锁(最大等待时间500ms) if (mutex.WaitOne(500)) { // 临界区代码 } } finally { if (mutex != null) { mutex.ReleaseMutex(); } }关键特性:
支持跨应用程序域同步
线程终止时自动释放锁
支持命名互斥体(系统全局可见)
适用场景:
单实例应用程序控制
进程间共享文件访问
硬件设备独占访问
信号量(Semaphore)
核心作用:
通过许可计数器控制并发线程数,SemaphoreSlim为轻量级版本(用户态实现)。
实现对比:
类型 跨进程 性能 最大许可数 Semaphore ✔️ 低 系统限制 SemaphoreSlim ❌ 高 Int32.Max 代码示例:
// 创建初始3许可、最大5许可的信号量 var semaphore = new SemaphoreSlim(3, 5); semaphore.Wait(); // 获取许可 try { // 资源访问代码 } finally { semaphore.Release(); }异步编程
private readonly SemaphoreSlim _asyncLock = new(1, 1); public async Task UpdateAsync() { await _asyncLock.WaitAsync(); try { /* 异步操作 */ } finally { _asyncLock.Release(); } }典型应用:
数据库连接池(限制最大连接数)
API 请求限流
批量任务并发控制
事件(Event)
核心机制:
通过信号机制实现线程间通知,分为两种类型:
类型 信号重置方式 唤醒线程数 AutoResetEvent 自动 单个 ManualResetEvent 手动 所有 使用示例:
var autoEvent = new AutoResetEvent(false); // 等待线程 Task.Run(() => { autoEvent.WaitOne(); // 收到信号后执行 }); // 信号发送线程 autoEvent.Set(); // 唤醒一个等待线程高级用法:
配合WaitHandle.WaitAll实现多事件等待
使用ManualResetEventSlim提升性能
读写锁(ReaderWriterLockSlim)
核心优势:
实现读写分离的并发策略,适合读多写少场景(如缓存系统)。
锁模式对比:
模式 并发性 升级支持 读模式(EnterReadLock) 多线程并发读 ❌ 写模式(EnterWriteLock) 独占访问 ❌ 可升级模式 单线程读→写 ✔️ 代码示例:
var rwLock = new ReaderWriterLockSlim(); // 读操作 rwLock.EnterReadLock(); try { // 只读访问 } finally { rwLock.ExitReadLock(); } // 写操作 rwLock.EnterWriteLock(); try { // 排他写入 } finally { rwLock.ExitWriteLock(); }最佳实践:
优先使用ReaderWriterLockSlim(旧版有死锁风险)
避免长时间持有读锁(可能饿死写线程)
原子操作(Interlocked)
原理:
通过CPU指令实现无锁线程安全操作。
常用方法:
int counter = 0; Interlocked.Increment(ref counter); // 原子递增 Interlocked.Decrement(ref counter); // 原子递减 Interlocked.CompareExchange(ref value, newVal, oldVal); // CAS操作适用场景:
简单计数器
标志位状态切换
无锁数据结构实现
自旋锁(SpinLock)
核心特点:
通过忙等待(busy-wait)避免上下文切换,适用极短临界区(<1微秒)。
实现示例:
private SpinLock _spinLock = new SpinLock(); public void CriticalOperation() { bool lockTaken = false; try { _spinLock.Enter(ref lockTaken); // 极短临界区代码 } finally { if (lockTaken) _spinLock.Exit(); } }优化技巧:
单核CPU需调用Thread.SpinWait或Thread.Yield
配合SpinWait结构实现自适应等待
同步机制对比指南
机制 跨进程 开销级别 最佳适用场景 lock ❌ 低 通用临界区保护 Mutex ✔️ 高 进程间资源独占 Semaphore ✔️ 中 并发数限制(跨进程) SemaphoreSlim ❌ 低 并发数限制(进程内) ReaderWriterLockSlim ❌ 中 读多写少场景 SpinLock ❌ 极低 纳秒级临界区 Interlocked - 无锁 简单原子操作
选择原则:
优先考虑用户态锁(lock/SpinLock/SemaphoreSlim)
跨进程需求必须使用内核对象(Mutex/Semaphore)
读写比例超过10:1时考虑读写锁
自旋锁仅用于高频短操作(如链表指针修改)
通过以上结构化的分类和对比,开发者可以更精准地选择适合特定场景的线程同步方案。建议在实际使用中配合性能分析工具(如BenchmarkDotNet)进行量化验证。
💡 ASP.NET 的异步编程(async/await)本质是单进程内的线程调度,不算“跨进程”。每个 IIS 应用程序池对应一个独立的工作进程(w3wp.exe),不同用户访问同一应用程序池下的 ASP.NET 网站,两者的请求均由同一个 w3wp.exe 进程处理。可能跨进程的场景有:Web Garden 配置、多应用程序池部署等。
在 C# 中,除了常规锁机制(如 lock、Mutex、Semaphore 等),还有一些内置类型通过内部锁或无锁设计实现线程安全。以下是常见的几类:
线程安全集合(System.Collections.Concurrent)这些集合通过细粒度锁或无锁算法(如 CAS)实现线程安全,适合高并发场景。
ConcurrentDictionary:分段锁机制,将数据分片存储,每个分片独立加锁,减少锁竞争。
ConcurrentQueue / ConcurrentStack:基于原子操作(Interlocked)保证线程安全。
ConcurrentBag:每个线程维护本地存储,减少争用,适合频繁添加和移除的场景。
BlockingCollection:基于 ConcurrentQueue 和信号量(SemaphoreSlim)实现生产-消费者模式,支持阻塞和超时。
不可变集合(System.Collections.Immutable) 通过数据不可变性实现线程安全(无需锁),每次修改返回新对象。
Lazy 的线程安全初始化(Lazy<T>) 通过锁或 Interlocked 确保延迟初始化的线程安全。
通道(System.Threading.Channels)用于异步生产-消费者模型,内部通过锁和信号量管理容量限制。
内存缓存(System.Runtime.Caching.MemoryCache)内部使用锁保护共享状态,确保线程安全。
原子操作类型(Interlocked 类、Volatile 关键字、Unsafe 类)通过 CPU 指令实现无锁线程安全。
其他同步工具(Barrier、CountdownEvent)虽然不是严格意义上的锁,但用于协调线程。
在 .NET Framework 的缓存管理中,cacheMemoryLimitMegabytes 是一个关键配置属性,用于控制内存缓存(MemoryCache)实例的最大内存占用。以下是其具体用法及实现细节:
基本定义与作用
功能:通过 cacheMemoryLimitMegabytes 可设置 MemoryCache 实例允许占用的最大内存(单位:MB)。若缓存数据超过此限制,系统会自动淘汰旧条目。
默认值:默认值为 0,表示缓存基于计算机的物理内存自动管理(例如根据可用内存动态调整)。
配置方式
通过配置文件(web.config)
在 web.config 的 <system.runtime.caching> 节点下配置 namedCaches,示例:
<configuration> <system.runtime.caching> <memoryCache> <namedCaches> <add name="Default" cacheMemoryLimitMegabytes="500" physicalMemoryLimitPercentage="50" pollingInterval="00:05:00" /> </namedCaches> </memoryCache> </system.runtime.caching> </configuration>参数说明:
cacheMemoryLimitMegabytes:最大内存限制(例如 500 表示 500MB)。
physicalMemoryLimitPercentage:允许使用的物理内存百分比(可选)。
pollingInterval:缓存清理策略的轮询间隔(例如每5分钟检查一次)。
通过代码动态配置
在初始化 MemoryCache 时,通过 NameValueCollection 传递参数:
var config = new NameValueCollection { { "cacheMemoryLimitMegabytes", "500" }, { "physicalMemoryLimitPercentage", "50" }, { "pollingInterval", "00:05:00" } }; var cache = new MemoryCache("CustomCache", config);此方式适用于需要动态调整缓存策略的场景。
注意事项
优先级规则:
若同时配置了 cacheMemoryLimitMegabytes 和 physicalMemoryLimitPercentage,系统会选择两者中较小的值作为限制。
分布式缓存兼容性:
此属性仅适用于进程内缓存(如 MemoryCache),若使用 Redis 等分布式缓存需通过其独立配置管理内存。
监控与调试:
建议结合性能计数器(如 ASP.NET Applications 类别下的 Cache Total Entries)或日志记录模块(参考 web.config 的 <system.diagnostics> 配置)监控实际内存占用。
应用场景示例
场景:一个电商网站需要缓存商品目录数据,限制最大内存为 1GB。
配置实现:
<add name="ProductCatalogCache" cacheMemoryLimitMegabytes="1024" pollingInterval="00:10:00" />代码调用:
var productCatalog = MemoryCache.Default["ProductCatalog"];常见问题
Q:设置为 0 时缓存会无限制增长吗?
A:不会。此时缓存基于系统物理内存动态管理,通常上限为总内存的 70%-90%。
Q:如何验证配置已生效?
A:可通过 MemoryCache.GetCount() 统计条目数量,或使用性能监视器跟踪内存占用。









