Hi there 👋

这是一篇用于验证 Mermaid 图表功能是否正常工作的测试文章。 流程图 (Flowchart) graph TD A[开始] --> B{是否准备好？} B -->|是| C[执行任务] B -->|否| D[等待] D --> B C --> E[检查结果] E -->|通过| F[完成] E -->|失败| G[修复问题] G --> C 时序图 (Sequence Diagram) sequenceDiagram participant 客户端 participant 服务端 participant 数据库 客户端->>服务端: GET /api/posts 服务端->>数据库: SELECT * FROM posts 数据库-->>服务端: 返回数据 服务端-->>客户端: JSON 响应 类图 (Class Diagram) classDiagram class Blog { +String title +String description +getPosts() List +publish() void } class Post { +String title +Date date +String content +String[] tags +render() String } class Author { +String name +String email +String avatar } Blog "1" --> "*" Post : 包含 Post "*" --> "1" Author : 属于 甘特图 (Gantt Chart) gantt title 博客搭建计划 dateFormat YYYY-MM-DD section 基础设施 初始化 Hugo 项目 :done, infra1, 2025-07-01, 1d 配置 PaperMod 主题 :done, infra2, 2025-07-02, 1d 配置 GitHub Actions :done, infra3, 2025-07-03, 1d section 内容创作 写第一篇文章 :done, content1, 2025-07-15, 1d 添加搜索和归档 :done, content2, 2025-07-20, 2d Mermaid 测试 :active, content3, 2026-08-11, 1d section 未来计划 持续写作 : future1, 2026-08-12, 30d 状态图 (State Diagram) stateDiagram-v2 [*] --> 草稿 草稿 --> 审核中 : 提交审核 审核中 --> 已发布 : 审核通过 审核中 --> 草稿 : 退回修改 已发布 --> 已归档 : 归档 已归档 --> [*] 如果以上所有图表都能正常渲染，说明 Mermaid 功能配置正确。 ...

这篇文章梳理 Git 中所有代理配置方式，从简单的 git config 到 SSH 协议的 SOCKS5 隧道，一份指南全搞定。 为什么需要代理 访问 GitHub、GitLab 等平台时，有时会遇到 git clone 速度极慢甚至超时的情况。尤其是在国内网络环境下，给 Git 配置代理几乎是必备技能。 flowchart LR A[你的电脑] --> B{需要代理？} B -->|直连通畅| C[直接连接 Git 服务器] B -->|速度慢/超时| D[代理服务器] D --> E[Git 服务器github.comgitlab.com] C --> E 配置方式总览 Git 提供多种配置代理的途径，优先级从高到低： 配置方式 持久性 作用范围 -c 命令行参数 单次命令 单仓库 git config --local 写入 .git/config 单个仓库 git config --global 写入 ~/.gitconfig 当前用户 环境变量 Shell 会话级 当前终端 graph TD A[Git 发起网络请求] --> B{有 -c 参数？} B -->|是| F[使用 -c 指定的代理] B -->|否| C{有 local 配置？} C -->|是| G[使用 local 代理] C -->|否| D{有 global 配置？} D -->|是| H[使用 global 代理] D -->|否| E{有环境变量？} E -->|是| I[使用环境变量代理] E -->|否| J[直连] 一、HTTP/HTTPS 代理 这是最常用的方式，适用于 https:// 协议的仓库。 1.1 配置命令 # 全局设置 git config --global http.proxy http://127.0.0.1:7890 git config --global https.proxy http://127.0.0.1:7890 # 仅对当前仓库设置 git config --local http.proxy http://127.0.0.1:7890 # 查看当前配置 git config --global --get http.proxy # 取消代理 git config --global --unset http.proxy git config --global --unset https.proxy 1.2 带认证的代理 # 用户名密码认证 git config --global http.proxy http://user:pass@127.0.0.1:7890 # 特殊字符需要 URL 编码，@ → %40，: → %3A git config --global http.proxy http://user:p%40ss@127.0.0.1:7890 1.3 针对特定域名 只想给 GitHub 走代理，公司内网 GitLab 直连？按域名精准控制： ...

https://deerchao.cn/tutorials/regex/regex.htm 本文目标 30分钟内让你明白正则表达式是什么，并对它有一些基本的了解，让你可以在自己的程序或网页里使用它。 如何使用本教程 别被下面那些复杂的表达式吓倒，只要跟着我一步一步来，你会发现正则表达式其实并没有想像中的那么困难。当然，如果你看完了这篇教程之后，发现自己明白了很多，却又几乎什么都记不得，那也是很正常的——我认为，没接触过正则表达式的人在看完这篇教程后，能把提到过的语法记住80%以上的可能性为零。这里只是让你明白基本的原理，以后你还需要多练习，多使用，才能熟练掌握正则表达式。 除了作为入门教程之外，本文还试图成为可以在日常工作中使用的正则表达式语法参考手册。就作者本人的经历来说，这个目标还是完成得不错的——你看，我自己也没能把所有的东西记下来，不是吗？ 清除格式 文本格式约定：专业术语 元字符/语法格式 正则表达式 正则表达式中的一部分(用于分析) 对其进行匹配的源字符串 对正则表达式或其中一部分的说明 隐藏边注 本文右边有一些注释，主要是用来提供一些相关信息，或者给没有程序员背景的读者解释一些基本概念，通常可以忽略。 本文介绍的大部分正则语法，在不同的正则表达式引擎中都可以使用，但也有一些会有所差异。本文介绍的是 .Net 下的正则表达式，其它环境下的具体情况可以在读完本文后去参考官方文档，或者查看正则表达式引擎特性对比。 正则表达式到底是什么东西？ 在编写处理字符串的程序或网页时，经常会有查找符合某些复杂规则的字符串的需要。正则表达式就是用于描述这些规则的工具。换句话说，正则表达式就是记录文本规则的代码。 很可能你使用过Windows/Dos下用于文件查找的通配符(wildcard)，也就是*和?。如果你想查找某个目录下的所有的Word文档的话，你会搜索*.doc。在这里，*会被解释成任意的字符串。和通配符类似，正则表达式也是用来进行文本匹配的工具，只不过比起通配符，它能更精确地描述你的需求——当然，代价就是更复杂——比如你可以编写一个正则表达式，用来查找所有以0开头，后面跟着2-3个数字，然后是一个连字号“-”，最后是7或8位数字的字符串(像010-12345678或0376-7654321)。 入门 学习正则表达式的最好方法是从例子开始，理解例子之后再自己对例子进行修改，实验。下面给出了不少简单的例子，并对它们作了详细的说明。 假设你在一篇英文小说里查找hi，你可以使用正则表达式hi。 这几乎是最简单的正则表达式了，它可以精确匹配这样的字符串：由两个字符组成，前一个字符是h,后一个是i。通常，处理正则表达式的工具会提供一个忽略大小写的选项，如果选中了这个选项，它可以匹配hi,HI,Hi,hI这四种情况中的任意一种。 不幸的是，很多单词里包含hi这两个连续的字符，比如him,history,high等等。用hi来查找的话，这里边的hi也会被找出来。如果要精确地查找hi这个单词的话，我们应该使用\bhi\b。 \b是正则表达式规定的一个特殊代码（好吧，某些人叫它元字符，metacharacter），代表着单词的开头或结尾，也就是单词的分界处。虽然通常英文的单词是由空格，标点符号或者换行来分隔的，但是\b并不匹配这些单词分隔字符中的任何一个，它只匹配一个位置。 假如你要找的是hi后面不远处跟着一个Lucy，你应该用\bhi\b.*\bLucy\b。 这里，.是另一个元字符，匹配除了换行符以外的任意字符。*同样是元字符，不过它代表的不是字符，也不是位置，而是数量——它指定*``前边的内容可以连续重复使用任意次以使整个表达式得到匹配。因此，.*连在一起就意味着任意数量的不包含换行的字符。现在\bhi\b.*\bLucy\b的意思就很明显了：先是一个单词hi,然后是任意个任意字符(但不能是换行)，最后是Lucy这个单词。 如果同时使用其它元字符，我们就能构造出功能更强大的正则表达式。比如下面这个例子： 0\d\d-\d\d\d\d\d\d\d\d匹配这样的字符串：以0开头，然后是两个数字，然后是一个连字号“-”，最后是8个数字(也就是中国的电话号码。当然，这个例子只能匹配区号为3位的情形)。 这里的\d是个新的元字符，匹配一位数字(0，或1，或2，或……)。-不是元字符，只匹配它本身——连字符(或者减号，或者中横线，或者随你怎么称呼它)。 为了避免那么多烦人的重复，我们也可以这样写这个表达式：0\d{2}-\d{8}。这里\d后面的{2}({8})的意思是前面\d``必须连续重复匹配2次(8次)。 测试正则表达式 如果你不觉得正则表达式很难读写的话，要么你是一个天才，要么，你不是地球人。正则表达式的语法很令人头疼，即使对经常使用它的人来说也是如此。由于难于读写，容易出错，所以找一种工具对正则表达式进行测试是很有必要的。 不同的环境下正则表达式的一些细节是不相同的，本教程介绍的是微软 .Net Framework 4.x 下正则表达式的行为，所以，我向你推荐我编写的.Net下的工具 Regester。请参考该页面的说明来安装和运行该软件。 下面是Regester运行时的截图： 元字符 现在你已经知道几个很有用的元字符了，如\b,.,*，还有\d.正则表达式里还有更多的元字符，比如\s匹配任意的空白符，包括空格，制表符(Tab)，换行符，中文全角空格等。\w匹配字母或数字或下划线或汉字等。 下面来看看更多的例子： \ba\w*\b匹配以字母a开头的单词——先是某个单词开始处(\b)，然后是字母a,然后是任意数量的字母或数字(\w*)，最后是单词结束处(\b)。 \d+匹配1个或更多连续的数字。这里的+是和*类似的元字符，不同的是*匹配重复任意次(可能是0次)，而+则匹配重复1次或更多次。 \b\w{6}\b 匹配刚好6个字符的单词。 常用的元字符 .匹配除换行符以外的任意字符 \w匹配字母或数字或下划线或汉字 \s匹配任意的空白符 \d匹配数字 \b匹配单词的开始或结束 ^匹配字符串的开始 $匹配字符串的结束 元字符^（和数字6在同一个键位上的符号）和$都匹配一个位置，这和\b有点类似。^匹配你要用来查找的字符串的开头，$匹配结尾。这两个代码在验证输入的内容时非常有用，比如一个网站如果要求你填写的QQ号必须为5位到12位数字时，可以使用：^\d{5,12}$。 这里的{5,12}和前面介绍过的{2}是类似的，只不过{2}匹配只能不多不少重复2次，{5,12}则是重复的次数不能少于5次，不能多于12次，否则都不匹配。 因为使用了^和$，所以输入的整个字符串都要用来和\d{5,12}来匹配，也就是说整个输入必须是5到12个数字，因此如果输入的QQ号能匹配这个正则表达式的话，那就符合要求了。 和忽略大小写的选项类似，有些正则表达式处理工具还有一个处理多行的选项。如果选中了这个选项，^和$的意义就变成了匹配行的开始处和结束处。 字符转义 如果你想查找元字符本身的话，比如你查找.,或者*,就出现了问题：你没办法指定它们，因为它们会被解释成别的意思。这时你就得使用\来取消这些字符的特殊意义。因此，你应该使用\.和\*。当然，要查找\本身，你也得用\\. 例如：deerchao\.cn匹配deerchao.cn，C:\\Windows匹配C:\Windows。 重复 你已经看过了前面的*,+,{2},{5,12}这几个匹配重复的方式了。下面是正则表达式中所有的限定符(指定数量的代码，例如*,{5,12}等)： 常用的限定符 *重复零次或更多次 +重复一次或更多次 ?重复零次或一次 {n}重复n次 {n,}重复n次或更多次 {n,m}重复n到m次 下面是一些使用重复的例子： Windows\d+匹配Windows后面跟1个或更多数字 ^\w+匹配一行的第一个单词(或整个字符串的第一个单词，具体匹配哪个意思得看选项设置) 字符类 要想查找数字，字母或数字，空白是很简单的，因为已经有了对应这些字符集合的元字符，但是如果你想匹配没有预定义元字符的字符集合(比如元音字母a,e,i,o,u),应该怎么办？ 很简单，你只需要在方括号里列出它们就行了，像[aeiou]就匹配任何一个英文元音字母，[.?!]匹配标点符号(.或?或!)。 我们也可以轻松地指定一个字符范围，像[0-9]代表的含意与\d就是完全一致的：一位数字；同理[a-z0-9A-Z_]也完全等同于\w（如果只考虑英文的话）。 下面是一个更复杂的表达式：\(?0\d{2}[) -]?\d{8}。 这个表达式可以匹配几种格式的电话号码，像(010)88886666，或022-22334455，或02912345678等。我们对它进行一些分析吧：首先是一个转义字符\(,它能出现0次或1次(?),然后是一个0，后面跟着2个数字(\d{2})，然后是)或-或空格中的一个，它出现1次或不出现(?)，最后是8个数字(\d{8})。 “(”和“)”也是元字符，后面的分组节里会提到，所以在这里需要使用转义。 分枝条件 不幸的是，刚才那个表达式也能匹配010)12345678或(022-87654321这样的“不正确”的格式。要解决这个问题，我们需要用到分枝条件。正则表达式里的分枝条件指的是有几种规则，如果满足其中任意一种规则都应该当成匹配，具体方法是用|把不同的规则分隔开。听不明白？没关系，看例子： 0\d{2}-\d{8}|0\d{3}-\d{7}这个表达式能匹配两种以连字号分隔的电话号码：一种是三位区号，8位本地号(如010-12345678)，一种是4位区号，7位本地号(0376-2233445)。 \(0\d{2}\)[- ]?\d{8}|0\d{2}[- ]?\d{8}这个表达式匹配3位区号的电话号码，其中区号可以用小括号括起来，也可以不用，区号与本地号间可以用连字号或空格间隔，也可以没有间隔。你可以试试用分枝条件把这个表达式扩展成也支持4位区号的。 \d{5}-\d{4}|\d{5}这个表达式用于匹配美国的邮政编码。美国邮编的规则是5位数字，或者用连字号间隔的9位数字。之所以要给出这个例子是因为它能说明一个问题：使用分枝条件时，要注意各个条件的顺序。如果你把它改成\d{5}|\d{5}-\d{4}的话，那么就只会匹配5位的邮编(以及9位邮编的前5位)。原因是匹配分枝条件时，将会从左到右地测试每个条件，如果满足了某个分枝的话，就不会去再管其它的条件了。 分组 我们已经提到了怎么重复单个字符（直接在字符后面加上限定符就行了）；但如果想要重复多个字符又该怎么办？你可以用小括号来指定子表达式(也叫做分组)，然后你就可以指定这个子表达式的重复次数了，你也可以对子表达式进行其它一些操作(后面会有介绍)。 (\d{1,3}\.){3}\d{1,3}是一个简单的IP地址匹配表达式。要理解这个表达式，请按下列顺序分析它：\d{1,3}匹配1到3位的数字，(\d{1,3}\.){3}匹配三位数字加上一个英文句号(这个整体也就是这个分组)重复3次，最后再加上一个一到三位的数字(\d{1,3})。 不幸的是，它也将匹配256.300.888.999这种不可能存在的IP地址。如果能使用算术比较的话，或许能简单地解决这个问题，但是正则表达式中并不提供关于数学的任何功能，所以只能使用冗长的分组，选择，字符类来描述一个正确的IP地址：((2[0-4]\d|25[0-5]|[01]?\d\d?)\.){3}(2[0-4]\d|25[0-5]|[01]?\d\d?)。 理解这个表达式的关键是理解2[0-4]\d|25[0-5]|[01]?\d\d?，这里我就不细说了，你自己应该能分析得出来它的意义。 IP地址中每个数字都不能大于255. 经常有人问我, 01.02.03.04 这样前面带有0的数字, 是不是正确的IP地址呢? 答案是: 是的, IP 地址里的数字可以包含有前导 0 (leading zeroes). 反义 有时需要查找不属于某个能简单定义的字符类的字符。比如想查找除了数字以外，其它任意字符都行的情况，这时需要用到反义： 常用的反义代码 \W匹配任意不是字母，数字，下划线，汉字的字符 \S匹配任意不是空白符的字符 \D匹配任意非数字的字符 \B匹配不是单词开头或结束的位置 [^x]匹配除了x以外的任意字符 [^aeiou]匹配除了aeiou这几个字母以外的任意字符 例子： ...

我们知道， HTTP 请求发出后，⼀般会给服务器留⼀定的时间做响应，⽐如 3 秒，规定时间内没返回，就 认为是超时。 如果我们的 HTTP 请求将超时设置的很⼤，⽐如 30 秒， 在这 30 秒内只要服务器收到了扫码请求，就⽴⻢ 返回给客户端⽹⻚。如果超时，那就⽴⻢发起下⼀次请求。 这样就减少了 HTTP 请求的个数，并且由于⼤部分情况下，⽤户都会在某个 30 秒的区间内做扫码操作， 所以响应也是及时的。 using Microsoft.AspNetCore.Mvc; using System.Threading; [ApiController] [Route("api/[controller]")] public class LongPollingController : ControllerBase { private static List<string> _messages = new List<string>(); private static int _lastMessageId = 0; private static object _lockObject = new object(); // 发送消息的端点 [HttpPost("send")] public IActionResult SendMessage([FromBody] MessageRequest request) { lock (_lockObject) { _messages.Add(request.Message); _lastMessageId++; } return Ok(new { Status = "Message sent" }); } // 长轮询接收消息的端点 [HttpGet("receive")] public async Task<IActionResult> ReceiveMessages(int lastId = -1, int timeoutSeconds = 30) { var startTime = DateTime.UtcNow; var endTime = startTime.AddSeconds(timeoutSeconds); while (DateTime.UtcNow < endTime) { List<string> newMessages; int currentLastId; lock (_lockObject) { currentLastId = _lastMessageId; newMessages = _messages.Skip(lastId + 1).ToList(); } // 如果有新消息，立即返回 if (newMessages.Count > 0) { return Ok(new { Messages = newMessages, LastId = currentLastId }); } // 等待一小段时间后再检查 await Task.Delay(500); } // 超时返回空结果 return Ok(new { Messages = new string[0], LastId = _lastMessageId }); } } public class MessageRequest { public string Message { get; set; } } 实现原理说明 服务端: 维护一个消息队列和最后消息ID 接收消息端点用于添加新消息到队列 长轮询端点循环检查是否有新消息，如果有则立即返回，否则等待一段时间继续检查直到超时 ...

MQTT 中的 retained（保留消息）是一个重要概念，主要作用如下： 基本定义 retained 是 MQTT 消息的一个标志位，当发布者发送消息时可以设置 RETAIN 标志为 true，这样的消息会被 MQTT 代理（broker）保存。 主要特性 消息持久化：Broker 会为每个主题保存最后一条带有 retain 标志的消息 新订阅者立即获取：当新的客户端订阅某个主题时，会立即收到该主题的最后一条保留消息 自动更新：当有新的保留消息发布到同一主题时，旧的保留消息会被替换 清除机制：发布一条空内容（payload 为空）的保留消息可以清除该主题的保留消息 使用场景 设备状态报告：传感器发布温度、湿度等状态信息 配置信息：系统配置参数的发布 在线状态：设备的上下线状态通知 初始数据：确保新订阅者能立即获得最新数据 工作示例 # 客户端A发布保留消息 PUBLISH topic:"home/temperature" payload:"25.6" retain:true # 客户端B稍后订阅该主题 SUBSCRIBE topic:"home/temperature" # 客户端B会立即收到之前发布的保留消息 MESSAGE topic:"home/temperature" payload:"25.6" retain:true 保留消息机制使得 MQTT 非常适合物联网场景，新设备上线时能立即获取到最新的状态信息，而不需要等待下一次数据更新。

Git 常用命令集合，Fork 自 tips 项目 Git 是一个分布式版本管理工具，版本管理工具就是大家在写东西的时候都用过 回撤这个功能，但是回撤只能回撤几步，假如想要找回我三天之前的修改，光用回撤是找不回来的。而版本管理工具能记录每次的修改，只要提交到版本仓库，就可以找到之前任何时刻的状态（文本状态）。 下面的内容就是列举了常用的 Git 命令和一些小技巧，可以通过页面内查找的方式 Ctrl/Command+f 进行快速查找。 开卷必读 如果之前未使用过 Git，可以学习 Git 小白教程入门 一定要先测试命令的效果后，再用于工作环境中，以防造成不能弥补的后果！到时候别拿着砍刀来找我 所有的命令都在 git version 2.7.4 (Apple Git-66) 下测试通过 统一概念： 工作区：改动（增删文件和内容） 暂存区：输入命令：git add 改动的文件名，此次改动就放到了 ‘暂存区’ 本地仓库(简称：本地)：输入命令：git commit 此次修改的描述，此次改动就放到了本地仓库，每个 commit，我叫它为一个版本。 远程仓库(简称：远程)：输入命令：git push 远程仓库，此次改动就放到了远程仓库（GitHub 等) commit-id：输出命令：git log，最上面那行 commit xxxxxx，后面的字符串就是 commit-id 如果喜欢这个项目，欢迎 Star、提交 Pr、反馈问题😊 展示帮助信息 git help -g The command output as below: The common Git guides are: attributes Defining attributes per path cli Git command-line interface and conventions core-tutorial A Git core tutorial for developers cvs-migration Git for CVS users diffcore Tweaking diff output everyday A useful minimum set of commands for Everyday Git glossary A Git Glossary hooks Hooks used by Git ignore Specifies intentionally untracked files to ignore modules Defining submodule properties namespaces Git namespaces repository-layout Git Repository Layout revisions Specifying revisions and ranges for Git tutorial A tutorial introduction to Git tutorial-2 A tutorial introduction to Git: part two workflows An overview of recommended workflows with Git 'git help -a' and 'git help -g' list available subcommands and some concept guides. See 'git help <command>' or 'git help <concept>' to read about a specific subcommand or concept. 回到远程仓库的状态 抛弃本地所有的修改，回到远程仓库的状态。 ...

为什么不建议使用存储过程了 在公司的系统升级换代中，明确规定在数据库开发中不允许再使用存储过程了，以前的老一代系统中，很多复杂的业务逻辑都是存储过程写的， 那为什么风光无限的存储过程不再被宠幸了呢？首先了解下什么是存储过程，它有什么好处，又有哪些劣势，为什么现在都不建议使用存储过程呢？ 什么是存储过程 存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL 语句集，预先编译好存储在数据库中， 一次编译后永久有效，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。它是数据库中的一个重要对象。 存储过程的优点 可以减少程序在调用DB时候的信息传输量（其实减少的只有Request的时候） 存储过程是预先优化和预编译的，节省每次运行编译的时间，所以一般情况下认为存储过程的性能是优于sql语句的。 对调用者可以隐藏数据库的复杂性，将数据组装的过程封装。 参数化的存储过程可以防止SQL注入式攻击，而且可以将Grant、Deny以及Revoke权限应用于存储过程。 如果业务开发中，数据人员和业务代码人员是分离的，业务人员可以不用关心数据，直接调用存储过程，更加面向分层开发设计理念。 存储过程的缺点 存储过程这种“一次优化，多次使用”的策略节省了每次执行时候编译的时间，但也是该策略导致了一个致命的缺点：可能会使用错误的执行计划。 存储过程难以调试，虽然有些DB提供了调试功能，但是一般的账号根本就没有那种权限，更何况线上的数据库不可能会给你调试权限的，再进一步就算能调试效果也比程序的调试效果要差很多。 可移植性差，当碰到切换数据种类的时候，存储过程基本就会歇菜。 如果业务数据模型有变动，存储过程必须跟着业务代码一起更改，如果是大型项目，这种改动是空前的，是要命的。 以上存储过程的优缺点，表面看来存储过程的优势还是不少的，这也说明为什么老一辈程序员有很多喜欢写存储过程。 但随着软件行业业务日益复杂化，存储过程现在复杂业务及大流量面前其实有点有心无力。 采用存储过程操作数据在网络数据量传输上确实比直接使用sql语句要少很多，但这通常并不是操作数据系统性能的瓶颈， 在一次操作数据的过程中，假设用时100毫秒，采用存储过程节省数据传输时间0.5毫秒（就算是5毫秒），我觉得这点时间基本可以忽略。 存储过程是只优化一次的，这有时候恰恰是个缺陷。 有的时候随着数据量的增加或者数据结构的变化，原来存储过程选择的执行计划也许并不是最优的了， 所以这个时候需要手动干预或者重新编译了，而什么时候执行计划不是最优的了这个平衡点，预先无法知晓， 这就导致了有些应用突然会变慢，程序员处于懵逼的状态。 存储过程确实可以对调用方隐藏数据库的细节，但是这种业务代码人员和数据库设计人员是两个团队的情况又有多少呢， 如果真是两个团队，那业务就需要两个团队来理解和沟通，我想沟通的成本也一定很高，而且分歧更容易产生。 我自己是有切身感受的，在接手的旧系统，令我头疼的不是业务，很多重要的业务逻辑都写在上千行的存储过程， 关键还没有调试的权限，在生产上也不能调试啊，出现个报错，都不知道如何怎么下手了。尤其是当有业务改动上线时， 必须要停掉所以相关的存储过程重新编译，总有一些莫名其妙的问题出现，相当烦躁！ 我认为数据库就应该做存储相关的事情，这也是它最擅长的事。现在的互联网的大流量冲击下， 如果把业务处理及计算放在数据库上，数据库的负载压力会特别大，肯定是顶不住的。 再说了，现在搞的都是分布式集群，分布式数据库，存储过程已经不能胜任了。

在我们分析查看IL之前首先要了解下什么是IL？IL的全称是Intermediate Language （IL）即将.NET代码转化为机器语言的一个中间语言的缩写。在一定程度上，我们可以将其理解为伪汇编语言。我们在使用.NET框架中的C#、VB.NET、F#等语言的时候，编译过程并不是像C/C++一样直接编译出原生代码，而是编译成IL中间语言。通过IL中间语言这种方式，可以实现跨平台、提高程序灵活性等多种优点。 首先编译器将我们编写好的源代码编译成IL中间语言，这些IL中间语言的主要内容是一些元数据和中间语言指令。然后再由我们的JIT编译器加载这些IL中间语言，JIT编译器会根据系统环境将IL中间语言指令转换为机器码，继而运行在不同的目标平台上，实现跨平台功能。（JIT编译器将IL中间语言即时编译成原生语言的过程和解释性语言的读取一条执行一条又有些不同，JIT会对编译结果进行缓存以便下次调取的时候直接使用）这也是为什么有些ASP.NET网站第一次运行时会较慢，而后面的执行速度则会相对快很多的一个原因。 再总结一下上面所说的编译过程： 首先，编译器要编历源代码，通过大量的计算生成IL中间代码，这些代码并不能直接地被CPU使用，还需要第二步操作； 接下来，运行时将这些IL代码通过JIT编译器进一步编译成原生的CPU指令。 在上文中我们提到了一个JIT编译器，它的全名叫即时编译器。顾名思义，它是在运行时环境中发生的编译行为。读到这里，相信很多朋友可能都会像马三一样产生疑问了。相比传统的直接将源代码编译成原生代码，C#将源代码编译成了中间语言不会降低效率嘛？原来直接一步到位的过程，现在偏要拆成两个部分。这不仅要花费更多的时间、占用更多的内存，还有可能降低性能，那用JIT编译器的好处到底有什么呢？ 在我们的Unity游戏开发中就存在着AOT编译和JIT编译两种编译方式 unity公司就自行研发了IL2cpp，把本来应该再mono的虚拟机上跑的中间代码转换成cpp代码，这样再把生成的cpp代码，利用c++的跨平台特性， 在各个平台上通过对各平台都有良好优化的native c++编译器编译，以获得更高的效率和更好的兼容性。 语言在运行之前通常都需要编译，JIT（Just-in-Time，即时编译） 和 AOT（Ahead-of-Time，预编译） 则是最常见的两种编译模式。 JIT 在运行时即时编译，在开发周期中使用，可以动态下发和执行代码，开发测试效率高，但运行速度和执行性能则会因为运行时即时编译受到影响。 AOT 即提前编译，可以生成被直接执行的二进制代码，运行速度快、执行性能表现好，但每次执行前都需要提前编译，开发测试效率低。 总结来讲，在开发期使用 JIT 编译，可以缩短产品的开发周期。 那么，如何区分一门语言究竟是 AOT 还是 JIT 呢？ 通常来说，看代码在执行前是否需要编译即可。如果需要编译，通常属于 AOT；如果不需要，则属于 JIT。 AOT 的典型代表是 C/C++，它们必须在执行前编译成机器码；而 JIT 的代表，则包括了如 JavaScript、Python 等几乎所有的脚本语言。

windows中文件的大小和文件的磁盘大小的区别是？ 在Windows中，文件的大小和文件的磁盘大小是不同的。 文件的大小指的是文件中实际存储的数据的大小，通常以字节（bytes）为单位表示。 这个大小是由文件的内容决定的，不受文件所在的磁盘格式和簇大小的影响。 而文件的磁盘大小（也称为簇大小）指的是文件在磁盘上所占用的空间大小， 通常以磁盘簇（cluster）为单位表示。 磁盘簇是操作系统用来管理磁盘空间的最小单位，它的大小取决于磁盘格式和簇大小设置。 如果文件的大小不是磁盘簇的整数倍，那么它所占用的磁盘空间将会超过实际的文件大小。 例如，如果磁盘的簇大小为4KB，而一个文件的大小为1KB， 那么这个文件在磁盘上所占用的空间将是4KB， 因为它必须占用一个完整的磁盘簇。因此，在考虑磁盘空间时， 需要注意文件的磁盘大小，而不是文件的实际大小。

解释一下IoC和DI的概念： IoC (Inversion of Control) - 控制反转 控制反转是一种软件设计原则，它将传统的程序控制流程颠倒过来： 传统方式：对象自己创建和管理依赖项 IoC方式：对象的依赖项由外部容器或框架来创建和注入 DI (Dependency Injection) - 依赖注入 依赖注入是实现IoC的一种具体方式，通过以下方式实现： 构造函数注入：通过构造函数传入依赖项 属性注入：通过属性设置依赖项 方法注入：通过方法参数传入依赖项 using System; using System.Collections.Generic; using System.Linq; public interface IContainer { void Register<TService, TImplementation>() where TImplementation : TService; void Register<TService>(Func<TService> instanceCreator); TService Resolve<TService>(); } public class Container : IContainer { private Dictionary<Type, Func<object>> _registry = new Dictionary<Type, Func<object>>(); public void Register<TService, TImplementation>() where TImplementation : TService { _registry[typeof(TService)] = () => Activator.CreateInstance(typeof(TImplementation)); } public void Register<TService>(Func<TService> instanceCreator) { _registry[typeof(TService)] = () => instanceCreator(); } public TService Resolve<TService>() { Func<object> creator; if (_registry.TryGetValue(typeof(TService), out creator)) { return (TService)creator(); } else { throw new Exception($"No registration for {typeof(TService)}"); } } }