自定义 tag helper 需通过 [htmlattributename] 绑定属性、在 process 中校验必填项并调用 output.suppressoutput()，使用 uri.escapedatastring 编码敏感值；taghelpercontext 只读、taghelperoutput 可写；服务注入须用 scoped/transient 且异步应重写 processasync；@addtaghelper 的程序集名必须与编译输出 dll 名完全一致。
如何让自定义 Tag Helper 接收并验证属性值
Tag Helper 不只是改标签名或加样式，关键是要能接收视图传入的参数，并做合理校验。比如一个 EmailTagHelper 需要 EmailTo 属性，但若用户漏写或填了非法邮箱，直接渲染 mailto: 会导致链接无效甚至 JS 报错。
常见错误现象：EmailTo 为空时仍生成 <a href="mailto:"></a>；或传入中文、空格导致 URL 编码异常。
- 用
[HtmlAttributeName]显式绑定属性名（避免大小写歧义），例如[HtmlAttributeName("email-to")] public string? EmailTo { get; set; } - 在
Process方法开头检查必填属性：if (string.IsNullOrWhiteSpace(EmailTo)) { output.SuppressOutput(); return; } - 对敏感值做 HTML 编码：
output.Content.SetContent(WebUtility.HtmlEncode(Content ?? string.Empty)) - 避免直接拼接 URL，改用
Uri.EscapeDataString(EmailTo)处理邮箱地址
为什么 TagHelperContext 和 TagHelperOutput 不能互换使用
很多人误以为 context 可以改输出内容，或 output 能读取父级上下文 —— 实际上它们职责严格分离：TagHelperContext 是只读元数据（如标签名、属性集合、是否已处理过），TagHelperOutput 才是唯一可写出口。
典型踩坑点：context.Attributes.SetAttribute("class", "x") 会报编译错误；而 output.Attributes["class"] = new TagHelperAttribute("class", "x") 才合法。
-
context.AllAttributes是IReadOnlyList<taghelperattribute></taghelperattribute>，不可修改 -
output.Attributes.SetAttribute()是安全写法，会自动去重；output.Attributes.Add()可能引发重复属性 - 若需判断是否已有某属性，用
output.Attributes.ContainsName("data-id")，别用context查 - 调用
output.SuppressOutput()后，后续所有对output的操作都失效，且不可逆
如何在 Tag Helper 中注入服务并确保生命周期正确
自定义 Tag Helper 经常需要访问数据库、缓存或配置服务。但直接在构造函数里注入 DbContext 或 IHttpClientFactory 很容易出问题 —— 因为 Tag Helper 实例由框架按需创建，不是单例，也不走常规 DI 生命周期管理。
错误做法：把 DbContext 声明为字段并直接调用 SaveChangesAsync；这会触发 EF Core 的并发异常或上下文已释放错误。
- 只注入
Scoped或Transient服务，禁止注入Singleton的有状态对象（如未包装的HttpClient） - 若需异步逻辑，继承
TagHelper并重写ProcessAsync，而非在同步Process里用.GetAwaiter().GetResult() - 从
TagHelperContext.Items获取请求级上下文数据（如当前用户 ID），比硬依赖IHttpContextAccessor更轻量 - 注册时用
services.AddTransient<icountryservice countryservice>()</icountryservice>，并在Program.cs中确保服务先于 Tag Helper 加载
为什么 @addTagHelper 写错程序集名就完全不生效
这是最隐蔽也最常被忽略的问题：@addTagHelper *, YourAssemblyName 中的 YourAssemblyName 必须与项目编译输出的 DLL 文件名（不含扩展名）**完全一致**，包括大小写和连字符。Windows 下可能“看似”生效，Linux 容器里直接静默失败。
现象：视图中写了 <email email-to="a@b.c">Contact</email>，但浏览器源码仍是原样，没被替换 —— 控制台无报错，调试断点也不进 Process 方法。
- 查 DLL 名：右键项目 →「属性」→「常规」→「程序集名称」，不是「默认命名空间」，也不是解决方案名
- 若项目用了
<packageid></packageid>或<assemblyname></assemblyname>覆盖，默认值会被覆盖，必须用实际生成的名称 - 临时排查：在
_ViewImports.cshtml中加一行@functions { public static string X = typeof(YourTagHelper).Assembly.GetName().Name; }，再在视图里@X输出确认 - 多项目依赖时，确保
MyWebApp引用了MyTagHelpers项目（而非仅 NuGet 包），否则编译期找不到类型
output.SuppressOutput() 配合条件断点，才能确认它到底有没有被框架选中。
