• 变量用途分析

  • 表示当前会话是否已完成登录认证（Authentication），用于接口鉴权、权限检查与受控资源访问的前置条件判断。
  • 语义核心：会话级别、已认证/未认证、布尔值。

• 命名规范符合性

  • 使用小驼峰命名，语义清晰且与布尔类型相匹配（偏向 is/has 前缀或形容词态）。
  • 避免与“授权”（Authorization）混淆，聚焦“认证”（Authentication）。
  • 不使用否定式命名，避免双重否定导致的可读性问题。

• 候选名称列表

  1. sessionAuthenticated
     • 含义：当前会话是否处于已认证状态。
     • 优点：明确作用域（会话级）、不与授权概念混淆；作为 JavaBean 字段时可生成 isSessionAuthenticated()，避免 is 前缀导致的 isIs 问题。
     • 适用：会话管理、鉴权过滤器、实体/DTO 字段。
  2. isSessionAuthenticated
     • 含义：会话是否已认证。
     • 优点：布尔语义直观；适合局部变量或条件判断使用。
     • 缺点：若作为 JavaBean 字段名，可能与部分框架的属性解析产生不一致（生成 isIsSessionAuthenticated 风险），不如无 is 前缀安全。
     • 适用：方法内临时变量、条件表达式。
  3. authenticated
     • 含义：是否已认证（默认指当前上下文/会话）。
     • 优点：最简洁；JavaBean 字段名自然生成 isAuthenticated()。
     • 缺点：作用域不够直观，需依赖上下文理解“是会话级还是用户级”。
     • 适用：上下文已明确是会话语境的代码（如 Session/Filter 内部）。
  4. isAuthenticated
     • 含义：是否已认证。
     • 优点：布尔直觉强；与通用术语一致。
     • 缺点：作为字段名在部分框架的属性映射可能出现 is 前缀二次解析问题；且容易与 Spring Security 的 isAuthenticated 概念混淆。
     • 适用：方法内局部变量、与框架方法名对齐的临时标志。
  5. loginVerified
     • 含义：是否完成登录校验。
     • 优点：贴近“登录验证”表述。
     • 缺点：偏业务词“登录”，在 Token/SSO 等非显式登录场景语义不够广泛；不如“authenticated”准确。
     • 适用：确实以“登录流程”为核心的场景。

• 推荐方案

  • 首选变量名：sessionAuthenticated
  • 推荐理由：
    • 语义准确：突出“会话级已认证”这一核心含义，避免与授权（authorized）混淆。
    • 可读性强：一眼可知作用域与状态，适合鉴权过滤器和会话管理代码。
    • 规范友好：作为字段可生成 isSessionAuthenticated()，既符合 JavaBean 习惯，又避免字段名以 is 开头带来的潜在解析问题。
    • 兼顾简洁：在明确会话语境下足够简短，比冗长的命名更易读。

• 使用注意事项

  • 与授权区分：不要使用 authorized/hasPermission 之类名称，此变量仅表示“认证完成”，非“已授权”。
  • 避免否定式：避免 notAuthenticated、unauthenticated 等命名，条件判断更易产生误读。
  • Bean 属性命名：若作为类字段并暴露给框架（序列化/绑定），优先使用 sessionAuthenticated 或 authenticated，避免以 is 开头的字段名导致 isIs... 的 getter。
  • 上下文一致性：在 Filter/Interceptor 中，确保该标志与实际认证来源一致（Cookie/Token/SSO），若存在匿名访问或部分认证态，考虑引入更精细的状态枚举或额外变量（例如 authenticationLevel）。

变量用途分析

• 存放富文本编辑器输出的文章正文 HTML 内容（包含段落、标题、内嵌图片、代码块）。
• 用途：在 CMS 的文章发布与预览流程中用于页面渲染，并作为全文索引的原始来源。
• 数据类型：String；生命周期通常为实体字段或 DTO 字段，也可能在服务层作为中间变量。

命名规范符合性

• 使用小驼峰命名法（lowerCamelCase），变量名以名词/名词短语为主。
• 缩略词 “HTML” 按 Java 惯例写作 “Html”（仅首字母大写），如：articleBodyHtml。
• 不包含不当缩写、拼音或含糊词；不与 Java 保留字或标准库类名冲突。
• 名称体现“是什么”（文章正文的 HTML），不过度编码“怎么用”（渲染/索引），避免职责耦合。

候选名称列表

1. articleBodyHtml

   • 说明：明确表示“文章正文的 HTML”。在有多字段（标题、摘要、封面等）的文章模型中可清晰区分“正文”。
   • 优点：语义准确、简洁；上下游开发者易于理解。
   • 适用场景：实体/DTO字段，服务层通用变量。

2. articleContentHtml

   • 说明：表示“文章内容的 HTML”。“content”更通用。
   • 优点：通用性强。
   • 可能问题：在同时存在 summary/abstract/description 时，“content”可能与这些概念混淆；不如“body”聚焦“正文”。

3. richTextContentHtml

   • 说明：强调来源是富文本（rich text）编辑器生成的 HTML。
   • 优点：来源清晰；适合靠近编辑器边界（接收/转换）处使用。
   • 可能问题：在远离编辑器的业务层，这种来源信息价值降低，名称略显冗长。

4. editorOutputHtml

   • 说明：突出“来自编辑器的输出 HTML”，强调“原始产物”语义。
   • 优点：非常适合短生命周期、紧邻输入边界（Controller/Adapter）的变量名，便于和“清洗后/转码后”区分。
   • 可能问题：偏过程性，强调来源而非实体语义；不适合作为实体字段的长期命名。

5. bodyHtml

   • 说明：简化形式的“正文 HTML”，依赖外层上下文（如 Article 类）。
   • 优点：在 Article 实体内部字段时足够清晰且更简洁。
   • 可能问题：在离开 Article 上下文的地方会显得语义不足；不符合“详细描述”偏好。

推荐方案

• 推荐名称：articleBodyHtml
• 推荐理由：
  • 语义聚焦：清楚指向“文章的正文”（body），区别于 title、summary、cover 等同级字段。
  • 表意完整：同时标明承载格式为 Html，避免与纯文本正文混淆。
  • 适配范围广：既适合作为 Article/ArticleDTO 的字段，也适合作为服务层变量；满足“详细描述”的风格偏好且不过度冗长。
  • 符合规范：小驼峰 + 合理处理缩略词（Html），无歧义、不依赖上下文才能理解。

使用注意事项

• 若存在“原始 HTML”和“安全清洗后 HTML”两种形态，建议区分命名：
  • 原始：rawArticleBodyHtml（仅在确需强调“未清洗”时使用）
  • 清洗：sanitizedArticleBodyHtml 或 safeArticleBodyHtml
• 若同时保存纯文本以便索引或摘要生成，建议并列字段：
  • articleBodyText（纯文本，去标签后）
• 避免把用途编码进名称（如 forRendering、forIndexing），保持“描述数据本身”的命名原则。
• 在 Article 类内部字段可使用更短的 bodyHtml，但在跨上下文（DTO、服务间）传递时更建议使用 articleBodyHtml，减少语义依赖。
• 若存在多格式并存（如 Markdown 与 HTML），需在命名中显式标注格式以避免混淆（articleBodyMarkdown / articleBodyHtml）。