C# - kitlau's blog

24

SEP

如何使用 AnduinOS 愉快的开发 .NET

在Linux系统上开发.NET应用时如何兼顾效率与成本？AnduinOS环境下VSCode的插件生态为开发者提供了新的可能性。通过C#插件与OmniSharp的深度整合，开发者可以在轻量级编辑器中获得智能感知、代码导航等核心功能。当C# Dev Kit带来接近Visual Studio的项目管理能力时，其许可证对商业团队的限制却成为隐性成本。Roslynator作为免费替代方案虽功能精简但内核强大，它基于500+分析器的代码优化能力，恰好映射了JetBrains Rider的开源精神与商业边界。XML文档注释生成器和命名空间自动补全等工具，将日常开发中的机械性操作转化为流畅的创作体验。而GitHub Copilot带来的AI编码革命，正在重新定义开发者对代码生产率的认知边界。当开源工具链与商业软件形成微妙平衡，开发者是否正在经历从IDE依赖向插件生态的范式转移？在AnduinOS的桌面环境下，.NET开发者的生产力工具箱究竟应该包含哪些关键组件？这些选择背后的技术考量与商业权衡，或许正是每个开发者都需要思考的命题。你是否也在寻找更高效的开发方式？--Qwen3

.NET C# VSCode AnduinOS dotnet vscode-plugins github-copilot development-environment

22

JUL

如何使用 Optional 模式解决 C# 中的烦人的空引用问题

Optional模式通过封装可选值避免显式null传递，结合编译期类型检查和链式调用机制，可系统性规避null reference异常风险，其核心优势体现在：1）函数式编程范式强制处理缺失值，如GroupBy操作时通过Map/Reduce自动传递空值状态，无需冗余的null判断逻辑；2）代码结构显式暴露可空性，如Person类的Author属性声明为Option类型而非Person?，在编译阶段即约束调用方必须处理空值场景；3）通过嵌套的Map/Reduce方法构建安全链式调用，在作者姓名长度计算等复杂场景中避免多层null检查的代码膨胀。相较于C# Nullable特性，Optional模式通过类型系统将空值处理逻辑从运行时提前到编译期，但代价是引入函数式编程的学习成本和代码复杂度提升，适合对安全性要求高且团队熟悉函数式思维的中大型项目，而Nullable特性则更适合需要快速迭代的简单业务场景。--Qwen3

C# Null Handling Null Safety Optional Pattern Functional Programming Type System

18

JUL

Linq 和 lambda 的区别是什么？

这篇博客通过剖析LINQ与lambda表达式的本质差异揭示了现代开发者过度追求技术堆栈而忽视基础能力的普遍现象。文章指出LINQ作为语言集成查询的语法体系本质是基于IEnumerable的扩展方法库其核心价值在于将查询逻辑与数据源解耦而lambda表达式则是通过=>运算符简化委托创建的语法糖两者在技术层级上存在根本差异——前者是查询范式后者是函数式编程工具。当开发者习惯用lambda表达式构建Where等方法的谓词时实际上是在使用一种更简洁的委托创建方式这种混淆往往源于教学材料中二者的高频共现。文章通过代码示例展示了LINQ查询表达式如何编译为方法链调用并进一步解析lambda表达式如何通过表达式树实现动态查询构建的能力这种将代码转化为数据结构的特性正是LINQ能映射SQL等异构查询的底层原理。当开发者将lambda视为LINQ的必需组件时容易忽略其可选性——通过具名函数或委托同样能实现相同功能这恰说明lambda本质是语法便利而非技术依赖。博客最后抛出一个值得深思的问题：当我们在ORM框架中构建复杂查询时是否真正理解了表达式树与数据库查询语言之间的映射关系？这种对技术本质的追问或许正是每个开发者都需要回归的基础能力。--Qwen3

C# linq lambda expressions expression trees entity relationship mapping Method Syntax

18

JUL

C# required：跟 string 的空引用异常说再见

C# 11 的 required 关键字为开发者提供了一个优雅的解决方案来规避字符串类型的空引用异常问题。文章通过一个典型的数据库映射场景展示了传统开发模式中的痛点——当开发者将数据库字段设计为可为 null 但代码模型声明为 string 类型时，既可能触发编译器警告又可能在运行时引发 NullReferenceException。这种矛盾在 C# 11 之前需要开发者使用 null! 断言或者修改数据库约束来强行消除警告，但本质上只是将问题从开发阶段转移到生产环境。required 关键字的出现打破了这种妥协，它强制要求属性必须在初始化时赋值，从而在代码层面建立了不可变的约束。这种设计不仅消除了 null 值的可能性，更将数据完整性验证提前到了对象构造阶段。文章更深层的讨论触及了软件开发领域的核心矛盾——在压缩工时与代码质量之间的博弈。当团队过度追求上线速度而忽视基础架构设计时，开发者被迫在代码中埋下隐患。required 关键字的出现恰恰揭示了一个值得深思的问题：当技术手段可以解决某个具体问题时，为何仍有大量项目选择在管理层面制造更多技术债务？文章通过对比外包模式与产品开发模式的异同，抛出了一个尖锐的质疑：在绩效考核体系驱动下，开发者是否正在沦为写代码的"码工"而非架构设计者？当单元测试被当作"不创造价值的累赘"时，我们究竟在用什么样的开发成本换取"快速上线"的光环？这些看似与技术无关的管理问题，或许才是导致空引用异常这类基础错误反复出现的根本原因。--Qwen3

C# Code Quality required keyword Nullables Engineering Practices Software Product Management

18

JUL

异步的原理是什么？C# 如何基于状态机实现异步？

C#异步通过状态机实现async/await机制，核心在于MoveNext方法的执行流程及状态切换。状态机通过state字段记录当前执行位置，结合switch-case跳转至对应代码块，实现异步操作的暂停与恢复。当await表达式执行时，若异步操作已完成（IsCompleted为true）则直接进入GetResult快速路径，否则保存当前状态至state字段并返回，等待后续恢复执行时通过状态码跳转至对应续延标签（如FirstAwaitContinuation）继续处理。状态机在暂停时通过builder.AwaitUnsafeOnCompleted注册回调，确保异步操作完成后触发MoveNext的再次调用。异常处理通过try-catch捕获异常并设置至builder，最终通过SetException传递结果，正常完成则调用SetResult。状态码-1表示尚未启动或正在执行，-2表示异常完成，0/1等数字对应不同await节点的状态，实现异步流程的精准控制。整个过程通过awaiter管理异步操作结果，结合状态保存与恢复机制，完成复杂的异步逻辑编排。--Qwen3

C# C# async programming State Machine Execution Paths Exception Handling Async Execution

18

JUL

什么是异步？异步就是多线程吗？异步就是 async、await 吗？

本文系统解析了C#异步编程的核心概念与实践方法重点阐述了Task异步任务模型的实现机制通过async/await关键字实现非阻塞操作的底层原理展示了Task.FromResult和Task.CompletedTask创建已完成任务的技巧分析了异步方法调用与await操作的执行时序揭示了不使用async修饰符也能返回Task的实现方式。通过多个代码示例验证了异步方法调用即刻执行的特性说明了await仅用于等待任务完成而非触发执行的逻辑，演示了Task.WhenAll实现多任务并行处理的优化方案，强调了理解异步编程原理对开发实践的重要性。--Qwen3

C# dotnet Async Await Task Parallelism Multithreading Task

18

JUL

EF Core 何时、为何使用 IsUnicode 方法

文章通过实验对比分析了EF Core中IsUnicode()配置在不同数据库中的实际作用。在MariaDB中该配置基本无效，因其UTF-8编码特性已默认支持Unicode；而在MSSQL Server中则会直接影响字段类型选择，使用IsUnicode(false)时生成varchar类型（非Unicode），默认或IsUnicode(true)生成nvarchar类型（Unicode）。作者建议仅在确定字符串为ASCII安全场景（如纯英文内容）时配置IsUnicode(false)，以节省存储空间和提升性能，尤其在处理大规模数据时效果显著。同时警示需谨慎处理URL等字段，因用户可能输入非ASCII字符，且现代应用需兼容emoji等扩展字符集。文章还指出EF Core 6新增的[Unicode]属性特性，并强调开发者应避免过度优化导致功能缺陷，需权衡存储成本与数据兼容性。--Qwen3

C# EF Core Entity Framework Core IsUnicode Method Database Design Model Configuration

18

JUL

EF Core 动态构建表达式树简化 DDD 值对象的比较

文章介绍通过动态构建表达式树实现值对象相等比较的方法解决EF Core查询异常问题。用户尝试直接使用lambda表达式比较实体中的值对象属性时抛出异常，通过创建ValueObjectEqualHelper静态类的CheckEqual方法动态生成表达式树，遍历值对象属性构建二叉树结构的条件表达式。该方法处理原始类型和非原始类型属性的不同比较方式，生成的表达式能正确转换为SQL查询条件，成功解决直接比较导致的异常问题，测试结果与预期一致且生成的SQL语句正确。--Qwen3

.NET C# EF Core expression trees Entity Framework Core Dynamic Condition Generation

18

JUL

手把手构建 C# 表达式树

文章通过构建 `p => p.Age > 18` 的 C# 表达式树示例，系统演示了从参数定义到最终 Lambda 表达式的完整创建过程。通过参数表达式、成员表达式、常量表达式与二元运算符的组合，逐步解析了如何将代码逻辑转化为可动态操作的表达式结构。文章不仅展示了如何将 `Where` 方法与表达式树结合实现动态筛选，更揭示了表达式树在 EF Core 等场景中动态构建查询的深层价值——例如通过值对象比较的语义化封装或软删除属性的全局过滤器设计，让原本需要硬编码的逻辑转化为可编程的动态规则。这种将代码作为数据的操作模式，既突破了传统 Lambda 表达式的静态限制，又为复杂业务规则的组合提供了新思路。当面对需要运行时动态构建查询条件的场景时，你是否想过用表达式树替代硬编码？如何让表达式树成为连接业务逻辑与数据访问层的桥梁？--Qwen3

.NET C# EF Core expression trees Dynamic Expression Linq Expressions

18

JUL

如何使用 CSharp 表达式树？

这篇博客深入探讨了CSharp表达式树的核心概念与实践应用，通过代码示例与结构化图示揭示了如何将代码逻辑转化为可操作的数据结构。文章从基础概念出发，解析了表达式树如何通过树形结构表示运算逻辑并转化为可执行代码，特别展示了`1+2*3`等表达式如何通过优先级拆解为嵌套子树。通过对比`Func<T>`与`Expression<TDelegate>`的本质差异，揭示了编译器如何将lambda表达式转化为可动态解析的抽象语法树，并演示了如何通过`Compile()`方法将表达式树转化为可执行委托。重点在于通过手动构建表达式树解决代码维护难题，以动态属性访问为例说明如何避免硬编码字符串导致的维护困境，通过`ParameterExpression`与`MemberExpression`的组合构建出可动态解析的表达式逻辑。文章指出这种动态构建方式虽然能灵活应对变化需求，但可能牺牲代码可读性，建议开发者在实际应用中权衡利弊。最后抛出思考：当面对动态查询需求时，如何在表达式树构建与传统代码结构之间找到最优解？是否还有其他技术方案能在保持灵活性的同时提升代码可维护性？这些问题或许会启发读者重新审视代码设计中的动态性与静态性的平衡点。--Qwen3

C# Functional Programming lambda expressions expression trees Dynamic Code Generation Property Access