命名空间是C#中组织类型、避免命名冲突的核心机制，应按公司名+项目名+模块名层级设计，不超过4级，同名非泛型类型不可共存，跨程序集同名类型不兼容。
命名空间是 C# 中组织类型、避免命名冲突的核心机制。合理设计命名空间结构，不仅能防止同名类/接口等互相干扰，还能提升代码可读性与团队协作效率。
命名空间应反映项目结构与业务层次
命名空间名称通常采用公司/组织名 + 项目名 + 模块名的层级方式，比如 MyCompany.ECommerce.Ordering 或 Acme.Core.Utilities。这样既体现归属，又明确职责边界。
- 顶层用公司或产品名（避免纯技术词如 “Common”、“Utils”）
- 中间层按功能域划分，如 Authentication、Reporting、Infrastructure
- 避免过深嵌套（一般不超过 4 级），否则引用冗长且难维护
同一命名空间内禁止重复类型名
C# 不允许在同一个命名空间下定义两个同名的非泛型类型（如两个 Customer 类）。编译器会报错 CS0101：“命名空间中已包含名为 ‘X’ 的定义”。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 若需相似概念，可用语义化后缀区分： CustomerDto、CustomerEntity、CustomerViewModel
- 泛型类型不受此限（List<T> 和 List<int> 是同一类型），但命名仍需清晰
使用 using 指令简化引用，但注意别名与隐藏风险
using 可导入命名空间，让代码更简洁；但多个 using 引入含同名类型的命名空间时，可能引发歧义。
- 用 using 别名 = 完整命名空间.类型; 解决冲突，例如：
using JsonReader = Newtonsoft.Json.JsonTextReader;
using System.Text.Json.JsonReader; - 避免无差别写 using static，尤其跨领域工具类，易造成方法来源不清晰
- IDE（如 Visual Studio）常提示“类型是模糊的”，此时需显式指定完整命名空间或添加别名
跨程序集时，命名空间相同 ≠ 类型兼容
两个不同程序集（DLL）可以有完全相同的命名空间和类名（如 Models.Product），但它们是完全独立的类型，不能直接赋值或转换。
- 这是常见误判点：命名空间只是逻辑分组，不是类型身份标识
- 若需互通，考虑共享类库、映射（AutoMapper）、或统一契约（如通过 NuGet 包发布公共模型）
- 检查引用是否指向预期程序集——右键查看类型定义，确认其来源 DLL
基本上就这些。命名空间本身不难，关键在早期约定和持续遵守。小项目可以简单，中大型项目必须靠它守住边界。
