Fortran如何自动在派生类型构造函数末尾执行抽象父类的sanity_check

有完全可行的实现方案，Fortran 2003及以上版本标准即可支持，不需要派生类开发者在构造函数内手动调用sanity_check，常用实现方式如下：

方案1：泛型构造接口+工厂函数（最常用，易维护） #

你可以在抽象基类base所在的模块中定义统一的泛型构造接口，所有派生类的实例化都走这个接口，接口内部会在完成派生类构造逻辑后自动调用sanity_check，示例实现逻辑：

module base_mod
  implicit none
  ! 原有抽象基类定义
  type, abstract :: base
  contains
    procedure :: sanity_check => base_sanity_check
  end type base

  ! 派生类定义（原有逻辑不变）
  type, extends(base) :: concrete1
    ! 原有成员定义
  end type concrete1
  interface concrete1
    module procedure init_concrete1 ! 原有构造函数
  end interface concrete1

  type, extends(base) :: concrete2
    ! 原有成员定义
  end type concrete2
  interface concrete2
    module procedure init_concrete2 ! 原有构造函数
  end interface concrete2

  ! 新增统一构造泛型接口
  interface new_base_instance
    module procedure new_concrete1
    module procedure new_concrete2
  end interface new_base_instance

contains
  ! 原有sanity_check实现
  subroutine base_sanity_check(this)
    class(base), intent(in) :: this
    ! 原有校验逻辑
  end subroutine base_sanity_check

  ! 原有concrete1构造函数实现
  function init_concrete1(args) result(res)
    ! 构造参数定义
    type(concrete1) :: res
    ! 原有构造逻辑
  end function init_concrete1

  ! 原有concrete2构造函数实现
  function init_concrete2(args) result(res)
    ! 构造参数定义
    type(concrete2) :: res
    ! 原有构造逻辑
  end function init_concrete2

  ! 新增concrete1包装构造逻辑
  function new_concrete1(args) result(res)
    ! 构造参数和concrete1原有参数一致
    type(concrete1) :: res
    ! 调用原有构造逻辑
    res = init_concrete1(args)
    ! 自动执行校验，无需派生类处理
    call res%sanity_check()
  end function new_concrete1

  ! 新增concrete2包装构造逻辑
  function new_concrete2(args) result(res)
    ! 构造参数和concrete2原有参数一致
    type(concrete2) :: res
    res = init_concrete2(args)
    call res%sanity_check()
  end function new_concrete2
end module base_mod

使用者构造实例时只需要调用new_base_instance接口即可，新增派生类时仅需要在泛型接口下新增对应包装函数，派生类本身的构造逻辑不需要做任何修改，也不需要手动调用校验函数。

方案2：final过程中转（适合需要兼容原有构造调用方式的场景） #

如果不想修改现有实例化的调用方式，也可以利用Fortran的最终过程（final procedure）特性配合状态标记实现：在base类型中增加一个initialized逻辑型标记，派生类构造完成赋值时触发临时实例的final过程，在final过程中判断如果是刚构造的实例就执行sanity_check并打标记，避免正常销毁实例时重复触发校验。这种方案不需要新增调用接口，但需要额外处理状态逻辑，相对更复杂，可根据实际场景选择。

你提到的抽象类型定义interface的方式完全适用，抽象类型虽然不能直接实例化，但可以作为多态参数类型，也可以定义绑定过程给所有派生类继承，完全符合当前需求。

内容的提问来源于stack exchange，提问作者Frank