方法一：打开 事件查看器-> Windows 日志-> 应用程序。
方法二：启用ASP.NET Core Module Stdout 日志。
修改网站根目录下的 web.config 文件，在 <aspNetCore> 节点中启用标准输出日志。你需要先手动创建 logs 文件夹并确保有写入权限。
<aspNetCore processPath="dotnet"
arguments=".\YourAppName.dll"
stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout"
hostingModel="inprocess" />重现错误后，即可在 logs 目录下查看生成的日志文件。注意：出于性能考虑，问题解决后建议将 stdoutLogEnabled 设为 false。
字段类型 | 是否分词 (Analyzed) | 是否索引 (Indexed) | 是否存储 (Stored) | 适用场景 |
|---|---|---|---|---|
Int32Field Int64Field | 否 | 是 | 由 Store参数决定 | 时间戳、数值等需要范围查询的字段 |
StringField | 否 | 是 | 由 | 订单号、身份证号、URL等需要精确匹配的字段 |
TextField | 是 | 是 | 由 | 文章标题、正文、描述等需要全文搜索的字段 |
StoredField | 否 | 否 | 是 | 仅用于存储，不参与搜索（如图片路径、文件等二进制数据） |
今天发现在 .NET Framework 和 .NET 9 中使用 System.Uri.EscapeDataString() 方法对字符串进行编码，会产生不同的结果。
譬如“(”符号，前者视其为非保留字符，不进行转义，后者视为保留字符，转义为“%28”。
原因是 .NET Framework 4.8 主要遵循 RFC 2396，而 .NET 9 遵循 RFC 3986。
在跨平台签名验证场景中，对 URL 编码的一致性要求极高，任何细微差别都会导致签名校验失败。
以下是以 RFC 3986 标准为核心、优先使用各平台内置的高一致性方案。
对于 .NET 9，直接使用 Uri.EscapeDataString()。
string encodedData = System.Uri.EscapeDataString(dataToEncode);对于 .NET Framework，以下是一个遵循 RFC 3986 严格标准的自定义编码方法示例。
static string Rfc3986EscapeDataString(string input)
{
// 定义 RFC 3986 中明确的未保留字符集（不编码）
var unreservedChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.~";
var result = new StringBuilder();
byte[] data = Encoding.UTF8.GetBytes(input); // 统一转换为 UTF-8 字节
foreach (byte b in data)
{
char currentChar = (char)b;
// 如果是未保留字符，直接输出
if (unreservedChars.IndexOf(currentChar) != -1)
{
result.Append(currentChar);
}
else
{
// 否则，进行百分号编码（%XX，大写）
result.Append('%').Append(b.ToString("X2"));
}
}
return result.ToString();
}对于 PHP，直接使用内置的 rawurlencode() 函数。这个函数的设计初衷就是严格遵循 RFC 3986 标准。
$encoded_data = rawurlencode($data_to_encode);对于 JavaScript，encodeURIComponent 函数严格遵循 RFC 3986 标准。
let encodedData = encodeURIComponent(dataToEncode);重要提示：无论使用哪种语言，务必在编码前明确指定字符串使用 UTF-8 编码。编码不一致是导致乱码和签名失败最常见的原因之一 。
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1
原因有很多，其中一种就是缺少主键。
一般地，应选择尺寸小于显存的大模型版本，且适当冗余。
譬如，显存 8GB，选择尺寸为 5.2GB 的 deepseek-r1:8b。
这样，整个大模型都能被完整地读取到显存中。
若选择 9.0GB 的 deepseek-r1:14b 则显存不足，Ollama 会自动调用系统内存和 CPU 来协同工作，导致推理速度显著下降。
显卡的算力影响生成的速度，模型的参数决定生成的质量。
另外经实测，在 /api/generate 接口的 format 参数中设置返回的 JSON 格式，会缩短生成时间，降低生成质量，可能的原因是强制格式限制了词汇选择空间。
今天遇到一个向基于 .NET Framework 框架开发的 Web 网站 POST 数据响应 405 Method Not Allowed 的问题。
服务端接口地址是 https://***/api/abc/Default.aspx，
若请求 https://***/api/abc/Default.aspx 或 https://***/api/abc/ 则正常 ，
若请求 https://***/api/abc 就会出现这个问题。
原因可能是服务器可能返回 301 重定向到 https://***/api/abc/Default.aspx，
导致最终接口接受到的请求方法不是 POST 。
查询路径：阿里云控制台 - 费用与成本 - 订购订单 - 企业服务产品订单
查询网址：https://billing-cost.console.aliyun.com/order/list/enterprise/paid
使用 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”字样的通常具备中枢网关功能。